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

【问题标题】：Should persistence logic be placed in domain model beans or in DAOs only?持久性逻辑应该放在域模型 bean 中还是只放在 DAO 中？
【发布时间】：2010-11-04 22:10:57
【问题描述】：

谁能解释一下这有什么优缺点？我的意思是，不使用 ORM 框架/JPA 规范。

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

老师 - 学生（多对多）

或

医生 - 患者（一对多）

我的问题是，我们是否可以将 getPatients() 方法放在 Doctor bean 或 getStudents() 放在 Teacher bean，或者是否应该是 POJO，所有这些东西都应该放在 DAO 层。

我经常看到第一种方法用于对象模型 bean 扩展类为它们提供对服务/持久性外观的访问，或者由 spring 注入它们等情况。它的优点是，可以调用医生.getPatients();几乎在应用程序的任何地方，而不是从 DAO 中获取结果。

在某些情况下第一种方法很方便吗？因为我看到很多情况都是这样做的，我想知道它是否有目的，或者它是业余爱好者还是旧风格。

【问题讨论】：

标签： java persistence dao

【解决方案1】：

你可以做任何你想做的事，但无处不在的模式是 DAO 模式。 重点是separate your concerns。如果你有一个域对象，那么你很可能在其中有一些业务逻辑。你真的想把持久性逻辑放在业务逻辑之上吗？您的应用程序将变得更难维护，更难（容易）测试，并且有更多错误。一旦你做出了一个有问题的设计决定，肯定会有更多人效仿....

【讨论】：

我也更喜欢严格关注分离的简单“Spring框架”方式，有pojos和dao层。但是我正在使用的一些（现代/年轻）软件正在使用第一种方法，所以我想知道为什么。对于我自己的应用程序开发，我只是坚持第二种方法，这是肯定的
@lisak 您应该在整个开发团队中采用一致的方法。
我在做我自己的项目，我懒得被雇用:-) 谢谢你的回复

【解决方案2】：

遵循 KISS 原则。 DAO 非常适合将持久性机制从域逻辑中抽象出来。领域对象只是简单地将状态从一层传递到另一层，通常在其中几乎没有业务逻辑。这意味着域对象（又名 DTO）可以有很多 JPA 注释来指示某种 ORM 框架的持久性，还有JAXB 注释来允许 DTO 轻松编组为 XML 以供 Web 服务传输.

我的总体趋势是让单个业务对象专用于对单个 DTO 进行操作，以便以某种由业务规则驱动的方式更改其状态。服务（它是 JTA 事务边界）管理业务对象的集合并实质上形成应用程序事务。这遵循了具有非常明确目的的大量细粒度对象的一般 OOD 原则。

【讨论】：

我也更喜欢一个专用于在单个 DTO 上操作的单个业务和持久性类......但我从来没有真正将服务视为“JTA 事务边界”，这似乎是一个非常好的实践。 ..很高兴知道
@lisak 感谢您的接受投票 :-) 您可能想看看这个 Stack Overflow 问题：stackoverflow.com/questions/1079114/…