JPA POJO作为数据对象

Question

使用JPA实体的最佳做法是什么？

由于JPA实体只是POJO,在系统的其他部分使用该对象作为数据对象是否合适,或者我应该将它们转换为另一个数据对象？

在与JPA无关的系统的其他部分中使用JPA实体POJO是否可以接受？

Answer 1

实体现在自己能够传输自己的数据,为什么还要将它们转换成其他东西呢？换句话说,我倾向于同意DTO是EJB 3.0中的AntiPattern:

EJB 3.0之前EJB规范中Entity Beans的重量级特性导致使用数据传输对象(DTO)等设计模式.DTO成为轻量级对象(首先应该是实体bean本身),用于跨层发送数据.[...]

EJB 3.0规范使Entity bean模型与Plain old Java对象(PO​​JO)相同.使用这个新的POJO模型,您将不再需要为每个实体或一组实体创建DTO.如果要跨层发送EJB 3.0实体,则只需实现它们java.io.Serialiazable.

Answer 2

这是一个很好的问题.

通过将JPA实体类公开给系统的其余部分,您可以将持久性机制和对象公开给db mapping.您无法控制这些对象的CRUDded和托管方式.通过打破持久性封装,更改可能会对系统的其余部分产生连锁反应.

系统持久性的未来变化可能是不可能的,尴尬的,有限的和/或有风险的.示例:您可能需要针对性能和/或可伸缩性进行优化.这可能需要缓存,数据库架构更改,非RDBMS使用,多个数据库.封装还有助于减少迁移到未来的数据库模式.

所以权衡是:

• 在JPA之上管理和维护应用程序持久层,它封装了持久性.即一个界面.要么
• 决定在您的架构中全面使用JPA.接受未来变化可能产生系统影响的事实.

如果不能接受频繁的系统范围更改,则可能需要第一个选项 - 例如,第三方正在访问您的数据.或许您已经决定采用3层架构:GUI,业务逻辑,持久性.

如果你有一个灵活的开发过程并且可以控制整个系统并且接受系统范围内的更改可能需要下线这一事实,那么第二个选项就可以了.