Java hibernate实体的setter中的额外操作

我正在用hibernate做一个遗留项目。有时我会发现开发人员在实体对象的集合方法中编写额外代码的代码。我想知道这是否是一种公认的做法？hibernate实体对象不应该只是带有额外注释和一些@Transient helper方法的pojo类吗

如果您想执行额外的操作，那么与实体一起工作的服务/dao的责任不就在于此吗

---

最佳做法是什么？有人知道有博客或公认的文章解释这一点吗？

嗯，这两种方法都是正确的。它们都有其优点和缺点。这与永恒的战争有关

关于Hibernate，它非常灵活。它可以让你采取你想要的任何一种方法。解决方案的性能和正确性并不取决于您所做的决定，而是取决于查询、数据库索引、实体获取策略、所选算法、I/O处理、并发实现、事务管理等的正确性

如果使用DDD，实体将是业务层的一部分，而Hibernate本身（会话、SessionFactory和整个ORM）将是持久层的一部分。在本例中，实体将包含与持久性相关的注释，这只是ORM的提示

您还应该注意事务管理。这最好在实体之外完成。（实际上，贫血模型的一个主要优点是事务管理非常简单，因为您将业务层的每个服务方法都封装在一个事务单元中）

---

正如您所提到的，您混合了这两种“意识形态”，也许您可以利用这一事实作为优势：让服务方法将逻辑委托给域实体，但在您的业务服务中保留事务管理。

这两种方法都是正确的，IMHO。搜索贫血模型vs dddWell我确实读过下面的wiki条目概念，我已经知道了，但我仍然想知道在hibernate特定的情况下，最好的方法是什么。在阅读了这个wiki之后，我不得不承认在实体中编写逻辑才是真正的OO方式。但是，如果您在域层中编写所有内容，那么为什么要有一个包含服务的业务逻辑层呢；它可以让你采取你想要的任何一种方法。性能将不取决于此决策，而是取决于查询、实体的获取策略、所选算法、I/O、并行执行等。如果您使用DDD，实体位于业务层，而Hibernate本身（会话、SessionFactory和整个ORM）将是持久层的一部分。我可以接受这一点，只是希望他们选择DDD或者贫血，因为现在它实际上是两种“意识形态”的混合体。如果你可以将此作为问题的答案发布，我可以将此问题标记为已回答并关闭它。只需发布答案。如果您需要进一步的澄清等，请告诉我。