在我们遗留的 Java EE 应用程序中，有大量值对象 (VO) 类，它们通常只包含 getter 和 setter，也许equals() and hashCode()。这些（通常）是要保存在持久性存储中的实体。 （根据记录，我们的应用程序没有 EJB - 尽管might将来会发生变化 - 并且我们使用 Hibernate 来持久化我们的实体。）操作 VO 中数据的所有业务逻辑都位于单独的类中（不是 EJB，只是 POJO）。我的面向对象心态讨厌这一点，因为我确实相信给定类上的操作应该驻留在同一个类中。所以我有一种重构的冲动，将逻辑转移到相关的 VO 中。
我刚刚与一位在 Java EE 方面比我更有经验的同事进行了讨论，他确认哑实体至少曾经是推荐的方法。然而，他最近也看到了质疑这一立场有效性的观点。
我知道存在一些问题至少限制了实体类中可以放入的内容：
- 它不应该直接依赖于数据层（例如查询代码应该进入单独的 DAO）
- 如果它直接暴露给更高层或客户端（例如通过 SOAP），则可能需要限制其接口
还有更正当的理由吗not将逻辑转移到我的实体中？或者还有其他需要考虑的问题吗？
The DTO and VO应该用于传输数据并且不嵌入逻辑。这业务对象另一方面应该嵌入一些逻辑。我说some，因为在协调涉及多个业务对象的逻辑的服务中放置的内容与在业务对象本身中放置的内容之间始终需要找到平衡。业务对象中的典型逻辑可以是验证、字段计算或其他一次仅影响一个业务对象的操作。
请注意，我没有提到这个词entity迄今为止。持久性实体随着 ORM 的普及而流行，现在我们尝试使用持久性实体作为 DTOand同时业务对象。也就是说，实体本身在层与层之间流动，并包含一些逻辑。
还有什么更正当的理由不
将逻辑转移到我的实体中？或任何
其他需要考虑的问题？
正如您所指出的，这完全取决于依赖关系和您公开的内容。只要实体是哑的（接近 DTO），它们就可以轻松地隔离在一个专用的 jar 中，用作层的API。您在实体中放入的逻辑越多，做到这一点就越困难。注意你公开的内容和依赖的内容（加载类时，客户端也需要有依赖的类）。这适用于异常、继承层次结构等。
举个例子，我有一个项目，其中实体有一个方法toXml(...)在业务层使用。因此，实体的客户端依赖于 XML。
但是，如果您不太关心层以及 API 和实现之间的严格分离，我认为在实体中移动一些逻辑是很好的。
EDIT
这个问题已经讨论过很多次了，并且可能会继续讨论，因为没有明确的答案。一些有趣的链接：
-
消气剂消除器 http://martinfowler.com/bliki/GetterEradicator.html
- 贫血域模型 http://en.wikipedia.org/wiki/Anemic_Domain_Model
-
封闭的重要性 http://codecourse.sourceforge.net/materials/The-Importance-of-Being-Closed.pdf
- 领域建模 http://www.aptprocess.com/whitepapers/DomainModelling.pdf
- 我的业务逻辑去哪里了？ http://blog.unhandled-exceptions.com/index.php/2008/12/26/services-anemic-domain-models-and-where-does-my-business-logic-go/
- 传输对象与业务对象 https://dzone.com/articles/transfer-obejcts-vs-business
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
