企业Java实体应该是愚蠢的吗？

Question

企业Java实体应该是愚蠢的吗？

在我们的遗留Java EE应用程序中,有许多值对象(VO)类,它们通常只包含getter和setter,也许equals()和hashCode().这些(通常)是要在持久性存储中保存的实体.(为了记录,我们的应用程序没有EJB - 尽管未来可能会发生变化 - 我们使用Hibernate来持久保存我们的实体.)操作VO中数据的所有业务逻辑都在不同的类中(不是EJB,只是POJO) ).我的OO心态讨厌这个,因为我确实认为给定类的操作应该驻留在同一个类中.所以我强烈要求重构将逻辑转移到相关的VO中.

我刚刚与一位在Java EE方面比我更有经验的同事进行了讨论,并且他证实了愚蠢的实体至少曾经是推荐的方式.不过,他最近也阅读了有关这一立场有效性的意见.

我知道有些问题至少限制了实体类中的内容:

它不应该直接依赖于数据层(例如,查询代码应该进入单独的DAO)
如果它直接暴露于更高层或客户端(例如通过SOAP),则可能需要限制其接口

有没有更合理的理由不将逻辑移入我的实体？还是要考虑其他任何问题？

Answer 1

ewe*_*nli 20

的DTO和VO都应该被用来传输数据和没有嵌入逻辑.另一方面,业务对象应该嵌入一些逻辑.我说一些,因为在服务中放置的涉及多个业务对象的逻辑与您在业务对象本身中放置的内容之间总是存在平衡.业务对象中的典型逻辑可以是验证,字段计算或一次仅影响一个业务对象的其他操作.

请注意,到目前为止我还没有提到术语实体.使用ORM推广持久化实体,我们现在尝试同时使用持久化实体作为DTO 和业务对象.也就是说,实体本身在层和层之间流动,并包含一些逻辑.

有没有更合理的理由不将逻辑移入我的实体？还是要考虑其他任何问题？

正如您所指出的,这完全取决于依赖性和您所暴露的内容.只要实体是哑巴(靠近DTO),它们就可以很容易地在专用的罐子中隔离,作为层的API.你在实体中投入的逻辑越多,就越难做到这一点.注意你暴露的内容和你所依赖的内容(类的负载,客户端也需要拥有依赖类).这适用于异常,继承层次结构等.

举一个例子,我有一个项目,其中实体有一个toXml(...)在业务层中使用的方法.因此,实体的客户端依赖于XML.

但是如果你不太关心层,以及API和实现之间的严格分离,我认为在实体中移动一些逻辑是好的.

编辑

这个问题已经讨论了很多次,可能会继续讨论,因为没有明确的答案.一些有趣的链接:

Answer 2

Pad*_*rag 8

我认为你的观点是有效的.
有关详细信息,请参阅此内容 - http://martinfowler.com/bliki/AnemicDomainModel.html
使用JPA,实体是轻量级对象.所以我认为它没有任何问题.

如果使用SOAP/Web服务,我会添加一个单独的Facade Layer.

同意.使用只有getter和setter的对象完全反对OO并且更像是在C中使用结构.我喜欢C,但是这是Java,每次我必须涉及除了包含样板的锅炉板代码之类的类时我都会畏缩getX()和setX() (3认同)
我认为调用MVC模式的问题在于它实际上是3种GoF设计模式的组合:Observer,Composite和Strategy.这三种模式的结合形成了"架构"设计模式. (2认同)

归档时间：	15 年，6 月前
查看次数：	4926 次
最近记录：	8 年，5 月前