Hibernate: Entité - Interface DAO - Classe DAO - Service (est-ce une bonne pratique?)

Question

J'ai récemment commencé à chercher dans Hibernate. J'ai recherché les meilleures pratiques concernant la couche des classes liées à Hibernate et une chose qui revient toujours est la structure suivante: Chaque entité a sa propre interface DAO, qui à son tour a sa propre classe d'implémentation DAO, qui à son tour a son propre service.

Est-ce considéré comme la meilleure pratique? Mon problème avec cela est que beaucoup de code est répété ou est fondamentalement le même pour chaque entité. Et franchement, 4 fichiers pour chaque modèle me semble un peu trop.

Je comprends comment les interfaces pour DAOs facilitent la modification des frameworks et des tests. Et je suis d'accord sur le fait que pour certains d'entre eux, vous avez besoin d'une séparation entre le DAO et le service (car vous voulez minimiser les fonctionnalités DAO et ajouter une logique métier supplémentaire dans le service).

Mais certaines entités n'ont besoin que d'une logique simple, et le DAO est plus que suffisant pour elles. Devraient-ils encore avoir leur propre classe de service? Et si un bon nombre d'entités auront toujours besoin de la même fonctionnalité de base? Leurs DAO ne peuvent-ils pas partager une interface commune? (au lieu d'en écrire une pour chacun d'entre eux)

En conclusion, une approche adaptative à chaque entité ne serait-elle pas mieux adaptée ou serait-ce que cela romprait la prévisibilité du code?

Answer 1

Il est recommandé de garder chaque couche séparée. Vous réaliserez son importance lorsque la complexité de votre application commencera à augmenter.

Vous pouvez fournir une super classe générique avec des fonctionnalités communes implémentées et étendre cette classe à toutes les classes d'implémentation d'entité. Cela réduira la répétition du code dans la couche dao.

Answer 2

Si vous allez utiliser Hibernate alors Hibernate est essentiellement l'implémentation DAO et DAO faite pour vous. Aussi, quand vous parlez Hibernate je suppose que vous voulez dire JPA, d'autant plus que le Hibernate critères semble être getting deprecated. Je pense que se diriger vers l'APP est une bonne idée.

Si vous avez une couche de service pour chaque entité, vous ne comprenez pas ce qu'est une couche de service. Généralement une couche de service defines an application boundry, mais j'aime l'expliquer comme un point de vue dans le domaine de persistance. Ainsi, si la gestion est un client de votre application, vous disposez alors d'une couche de service de gestion qui gère la logique métier de gestion (par exemple, les rapports, les performances commerciales, la sécurité). La couche de service de vente peut renvoyer toutes les commandes d'un client alors que la couche de service d'expédition peut renvoyer tout l'ordre d'une adresse. Vos beans de service, généralement des EJB sans état, vont s'interfacer avec toutes les entités de persistance dont ils ont besoin pour obtenir ce dont ils ont besoin.

Espérons que cela aide.