Should persistence logic be placed in domain model beans or in DAOs only?

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 an开发者_JAVA百科d I'm wondering whether it has a purpose or it is amateurism or the old style.

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....

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.