持久性逻辑应该放置在域模型 bean 中还是仅放置在 DAO 中？
请问有人可以解释一下这有什么优点和缺点吗？我的意思是，不使用 ORM 框架/JPA 规范。
它涉及实体之间的多对多和多对一关系。想象实体关系
教师 - 学生（多对多）
或
医生-病人（一对多）
我的问题是，我们是否可以将 getPatients() 方法放在 Doctor bean 或 getStudents() 放在 Teacher bean 上，或者它是否应该是 POJO 并且所有这些东西都应该放在 DAO 层中。
我经常看到第一种方法用于以下情况：对象模型 bean 扩展类，为它们提供对服务/持久化外观的访问权限，或者由 spring 注入它们等。它的优点是，可以调用 doctor.getPatients ();实际上在应用程序中随处可见，而不是从 DAO 获取结果。
在某些情况下第一种方法很方便吗？因为我看到很多情况都是这样做的，我想知道它是否有目的，或者是业余主义或旧风格。
Could please anybody explain what are pros and cons of this? I mean, without using ORM framework/JPA specification.
It concerns many-to-many and many-to-one relationships between entities. Imagine entity relationship
teacher - student (many-to-many)
or
doctor - patient (one-to-many)
My question is, whether we could put getPatients() method at Doctor bean or getStudents() at Teacher bean, or whether it should be POJOs and all this stuff should be placed in DAO layer.
I often see the first approach to be used in cases where the object model beans either extend classes that supply them with access to service / persistence Facades, or are injected by spring with them etc. It's advantage is, that one can call doctor.getPatients(); practically everywhere in the application instead of getting the results from DAO.
Are there situations in which the first approach is handy? Because I see a lot of cases where it is done exactly like that and I'm wondering whether it has a purpose or it is amateurism or the old style.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你可以做任何你想做的事，但普遍存在的模式是 DAO 模式。 重点是分离您的关注点。如果您有域对象，很可能你有一些业务逻辑在那里。您真的想将持久性逻辑放在业务逻辑之上吗？您的应用程序将变得更难维护，更难（容易）测试，并且有更多错误。一旦你做出了一项有问题的设计决定，更多的决定就会随之而来......
You can do anything you want, but the ubiquitous pattern is the DAO pattern. The point is to separate your concerns. If you have a domain object, chances are you have some business logic in there. Do you really want to put persistence logic in there on top of the business logic? You application will become less maintainable, less (easily) testable, and have more errors. And once you make one questionable design decision, more are sure to follow....
遵循 KISS 原则。 DAO 非常适合将持久性机制从领域逻辑中抽象出来。域对象只是将状态从一层传递到另一层，通常其中很少有业务逻辑。这意味着域对象（又名 DTO）可以有很多 JPA 注释来指示某种 ORM 框架的持久性，以及 JAXB 注释允许将 DTO 轻松编组为 XML，以便通过 Web 服务进行传输。
我的总体趋势是让单个业务对象专用于在单个 DTO 上进行操作，以由业务规则驱动的某种方式更改其状态。服务（JTA 事务边界）管理业务对象的集合，本质上形成应用程序事务。这遵循一般 OOD 原则，即大量具有非常明确目的的细粒度对象。
Follow the KISS principle. DAOs are great for abstracting the mechanics of persistence away from the domain logic. The domain objects simply carry state from one layer to the other, usually with very little business logic within them. This means that the domain objects (aka DTOs) can have lots of JPA annotations to indicate persistence with some kind of ORM framework, and also JAXB annotations to allow the DTOs to be marshalled easily to XML for transmission by a web service.
My general tendency is to have a single business object dedicated to operate on a single DTO to alter its state in some manner driven by the business rules. A service (which is the JTA transaction boundary) manages a collection of business objects and essentially forms an application transaction. This follows the general OOD principle of lots of fine grained objects with a very clear purpose.