企业Java实体应该笨吗？

Question

在我们的旧版Java
EE应用程序中，有很多价值对象（VO）类，它们通常仅包含getter和setter，也许equals()和hashCode()。这些（通常是）要保存在持久性存储中的实体。（为了记录，我们的应用程序没有EJB，尽管将来
可能会 改变，并且我们使用Hibernate来持久化实体。）所有在VO中操作数据的业务逻辑都在单独的类中（不是EJB，只有POJO）。
）。我的OO思维方式对此讨厌，因为我确实相信给定类的操作应位于同一类中。因此，我强烈希望将逻辑重构到相关的VO中。

我刚刚与一个比我在Java EE方面经验丰富的同事进行了讨论，他证实，笨拙的实体至少曾经是推荐的使用方式。但是，他最近也阅读了质疑这一立场是否合法的意见。

我了解有些问题至少限制了实体类中的内容：

• 它不应直接依赖于数据层（例如，查询代码应放入单独的DAO中）
• 如果直接暴露给更高层或客户端（例如，通过SOAP），则可能需要限制其接口

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

Answer 1

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

请注意，到目前为止，我还没有提到 实体 一词。持久性实体在ORM中得到了普及，如今，我们尝试将持久性实体同时用作DTO 和
业务对象。也就是说，实体本身在层和层之间流动，并包含一些逻辑。

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

正如您所指出的，这全都是依赖关系以及您公开的内容。只要实体是哑的（接近DTO），就可以轻松地将它们隔离在专用的jar中，用作 该层的API
。您在实体中放入的逻辑越多，执行此操作就越难。注意您公开的内容和所依赖的内容（加载类，客户端也需要具有依赖类）。这适用于异常，继承层次结构等。

仅举一个例子，我有一个项目，其中实体具有toXml(...)用于业务层的方法。结果，实体的客户依赖于XML。

但是，如果您不太在乎层次以及API与实现之间的严格分隔，那么我认为最好在实体中移动一些逻辑。

编辑

由于没有明确的答案，这个问题已经讨论了很多次，并且可能会继续讨论。一些有趣的链接：

• 消气剂
• 贫血领域模型
• 封闭的重要性
• 领域建模
• 我的业务逻辑去哪儿了？
• 转移对象与业务对象