La logique de persistance doit-elle être placée dans les beans de modèle de domaine ou dans les DAO uniquement?

Question

Pourriez-vous s'il vous plaît expliquer ce que sont les avantages et les inconvénients de cela? Je veux dire, sans utiliser la spécification ORM framework/JPA.

Il s'agit de relations plusieurs-à-plusieurs et plusieurs-à-un entre entités. Imaginez entité relation

professeur - étudiant (many-to-many)

ou

médecin - patient (un à plusieurs)

Ma question est, si nous pourrions mettre la méthode getPatients() à Doctor bean ou getStudents() au bean Teacher, ou si ce devrait être des POJOs et tout ce truc devrait être placé dans DAO lay er. Je vois souvent la première approche à utiliser dans les cas où les haricots du modèle objet étendent les classes qui leur fournissent l'accès aux façades de service/persistance, ou qui sont injectés par le printemps avec eux etc. Il est avantageux que l'on puisse appelez doctor.getPatients(); pratiquement partout dans l'application au lieu d'obtenir les résultats de DAO.

Y a-t-il des situations dans lesquelles la première approche est pratique? Parce que je vois beaucoup de cas où c'est fait exactement comme ça et je me demande si ça a un but ou si c'est de l'amateurisme ou de l'ancien style.

Answer 1

Suivez le principe KISS. Les DAO sont parfaits pour abstraire la mécanique de la persistance de la logique du domaine. Les objets du domaine portent simplement l'état d'une couche à l'autre, généralement avec très peu de logique métier en leur sein. Cela signifie que les objets de domaine (aka DTO) peuvent avoir beaucoup d'annotationspour indiquer la persistance avec une sorte de structure ORM, ainsi que des annotations JAXB pour permettre aux DTO d'être facilement rassemblés en XML pour transmission par un service Web.

Ma tendance générale est d'avoir un seul objet métier dédié à fonctionner sur un seul DTO pour modifier son état d'une certaine manière entraîné par les règles métier. Un service (qui est la frontière de transaction JTA) gère une collection d'objets métier et forme essentiellement une transaction d'application. Cela suit le principe général OOD de beaucoup d'objets à grain fin avec un objectif très clair.

Answer 2

Vous pouvez faire ce que vous voulez, mais le motif omniprésent est le motif DAO. Le point est separate your concerns. Si vous avez un objet de domaine, il est probable que vous ayez une logique métier. Voulez-vous vraiment mettre la logique de la persistance au-dessus de la logique métier? Votre application deviendra moins facile à maintenir, moins (facilement) testable, et aura plus d'erreurs. Et une fois que vous prenez une décision de conception douteuse, d'autres suivront ...