Couche de service vs DAO - Pourquoi les deux?

Je travaille avec SpringMVC, Hibernate et certaines bases de données dans un exemple d'application Web java.

Il en existe quelques-uns différents, mais ce tutoriel d'intégration Spring 3 et hibernate avec cet exemple contient une classe de modèle, une vue (en jsp) et un service et des classes de données pour le contrôleur.

Ma question est la suivante: les classes service et DAO ne font-elles pas la même chose? Pourquoi auriez-vous besoin des deux?

C'était le tutoriel que j'utilisais réellement: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

En règle générale, le DAO est aussi léger que possible et existe uniquement pour fournir une connexion à la base de données. Parfois, il est résumé afin que différentes bases de données puissent être utilisées.

La couche de service est là pour fournir une logique permettant d’exploiter les données envoyées vers et depuis le DAO et le client. Très souvent, ces 2 éléments seront regroupés dans le même module, et parfois dans le même code, mais vous les verrez toujours comme des entités logiques distinctes.

Une autre raison est la sécurité: si vous fournissez une couche de service sans relation avec la base de données, l'accès au client de la base de données est plus difficile, sauf via le service. Si la base de données n’est pas accessible directement à partir du client (et qu’il n’existe aucun module DAO trivial agissant en tant que service), tout attaquant ayant pris le contrôle du client peut tenter de pirater également la couche service avant d’obtenir la totalité des informations. accès le plus désinfecté à vos données.

Je suis l'auteur du post en question. J'ai eu ma part de travail sur différentes technologies et différentes architectures. Sur la base de ce qui précède, je peux affirmer sans crainte qu’il est toujours bon d’avoir une couche service et une couche dao. DAO devrait être limité à l'ajout, à la mise à jour, à l'insertion et à la sélection d'objets Entity dans / à partir de la base de données, et c'est tout. Si vous voulez faire quelque chose de plus en termes de logique, ajoutez-le à la couche service. Cela aidera à rendre le code modulaire et facilement remplaçable lorsque la base de données est remplacée (pour une partie des données). Ceci est particulièrement applicable dans les applications impliquant des rapports ayant une logique lourde même après avoir récupéré les données de la base de données.

De plus, au printemps, la sécurité s’applique idéalement au niveau de la couche service. Vous ne voudriez pas changer de cette façon.

Adam Bien souligne dans son livre que JPA EntityManager est une bonne implémentation universelle de la DAO:

http://realworldpatterns.com/

Dans le monde Java EE, il n'est presque jamais nécessaire d'écrire votre propre DAO car les implémentations JPA en incluent une. Vous devez seulement écrire la couche de service.

L'implémentation de votre propre couche DAO est en réalité une survivance de la très mauvaise architecture J2EE d'il y a 15 ans, mais de nombreuses personnes se sentent toujours obligées de le faire. Ces couches DAO personnalisées ne fournissent souvent rien de plus que des fonctions de transfert qui appellent la méthode correspondante sur EntityManager.

Donc, pour répondre à votre question, oui, vous avez besoin d’une couche service et d’un DAO, mais vous n’avez qu’à écrire la couche service.

Je mets généralement tout le code spécifique à la base de données (requêtes) dans les DAO ainsi que le traitement des transactions et la logique commerciale dans les services. Cela permet aux méthodes de service d'appeler des méthodes sur plusieurs DAO et de tout conserver au sein d'une même transaction. À mon avis, cela permet une meilleure réutilisation du code sur dao.

J'ai constaté que la couche de service ajoute une complexité inutile dans la plupart des cas. En théorie, il faut éviter de laisser des entreprises logiques dans la couche dao, mais à la fin, cela crée de la confusion, même certaines personnes n’ont plus l’intention de supprimer complètement la couche dao car elles estiment qu’elle n’ajoute aucune valeur. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

Mais si vous avez plusieurs logiques d’affaires, alors oui, c’est une bonne idée. Est-il essentiel de créer une couche de service?

IMHO la couche Service peut être considérée comme une couche entre le contrôleur et la couche DAO. Cette couche de service est l'endroit où nous pouvons ajouter une logique métier et même créer un objet de retour spécifique à ce qui doit être rendu par la vue.