Java 持久性逻辑应该放在域模型bean中还是只放在DAO中？

请任何人解释一下这有什么优点和缺点？我的意思是，不使用ORM框架/JPA规范

它涉及实体之间的多对多和多对一关系。想象实体关系

教师-学生（多对多）

或

医生-患者（一对多）

我的问题是，我们是否可以将getPatients（）方法放在DoctorBean或getStudents（）放在TeacherBean，或者它是否应该是POJO，所有这些东西都应该放在DAO层

我经常看到第一种方法用于对象模型bean扩展类，这些类为它们提供对服务/持久性外观的访问，或者spring将它们注入到类中，等等。它的优点是，可以调用doctor.getPatients（）；在应用程序中几乎无处不在，而不是从DAO获得结果

---

是否存在第一种方法方便的情况？因为我看到很多情况都是这样做的，我想知道它是有目的的，还是业余的还是老式的。

你可以做任何你想做的事情，但是无处不在的模式是DAO模式。关键是要做到这一点。如果您有一个域对象，那么很可能您在其中有一些业务逻辑。您真的想把持久性逻辑放在业务逻辑之上吗？您的应用程序将变得不易维护，不易测试，并且会出现更多错误。一旦你做出了一个有问题的设计决定，肯定会有更多的人遵循……遵循接吻原则。DAO非常适合将持久性机制从域逻辑中抽象出来。域对象只是将状态从一层传递到另一层，通常它们内部的业务逻辑很少。这意味着域对象（又名DTO）可以有很多注释来表示某种ORM框架的持久性，还可以有注释来允许DTO轻松地编组为XML，以便通过web服务进行传输

---

我的一般倾向是让一个业务对象专用于在一个数据上操作，以便在业务规则的驱动下以某种方式改变其状态。服务（JTA事务边界）管理业务对象的集合，并基本上形成应用程序事务。这遵循了大量细粒度对象的一般OOD原则，目的非常明确。

我也更喜欢简单的“Spring框架”方式，严格关注点分离，具有POJO和dao层。但是我正在使用的一些（现代/年轻）软件采用了第一种方法，所以我想知道为什么。对于我自己的应用程序开发，我只采用第二种方法，那就是sure@lisak在整个开发团队中，你应该有一个一致的方法。我正在做我自己的项目，我懒得被雇用：-）谢谢你的回复我也更喜欢一个业务和持久性类，专用于在单个DTO上操作…但我从来没有真正将服务看作“JTA事务边界”这似乎是一个很好的实践…对我来说很好know@lisak感谢您的接受投票：-）您可能想看看这个堆栈溢出问题：