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 Java.
Il y en a plusieurs différents qui font cela, mais cela Spring 3 et tutoriel d'intégration hibernate avec exemple a une classe de modèle, une vue (en jsp) et un service et des classes dao 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/
Généralement, le DAO est aussi léger que possible et existe uniquement pour fournir une connexion à la base de données, parfois abstrait de sorte que différents backends de base de données peuvent être utilisés.
La couche de service est là pour fournir une logique permettant d'opérer sur les données envoyées vers et depuis le DAO et le client. Très souvent, ces 2 pièces seront regroupées 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 qui n'a aucun rapport avec la base de données, il est alors plus difficile d'accéder au base de données à partir du client, sauf via le service. Si la base de données n'est pas accessible directement à partir du client (et qu'il n'y a pas de module DAO trivial agissant en tant que service), tout ce qu'un attaquant qui a pris le contrôle du client peut faire est de tenter de pirater la couche de service également avant d'obtenir tout sauf le accès le plus purifié à vos données.
Je suis l'auteur du post en question. J'ai ma juste part de travail sur différentes technologies et différentes architectures. Sur la base de ce qui précède, je peux dire en toute sécurité qu'avoir une couche service et une couche dao est toujours une bonne idée. DAO devrait être limité à seulement ajouter/mettre à jour/insérer/sélectionner des objets Entity dans/depuis 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 de 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 spécialement applicable dans les applications impliquant des rapports qui ont des logiques lourdes même après avoir récupéré des données de la base de données.
De plus, au printemps, la sécurité est idéalement appliquée à la couche de service. Vous ne voudriez pas changer de cette façon.
Adam Bien souligne dans son livre que le JPA EntityManager est une bonne implémentation universelle du DAO:
Dans le monde Java EE, il n'est presque jamais nécessaire d'écrire votre propre DAO car les implémentations JPA en incluent un. Vous n'avez qu'à écrire la couche de service.
L'implémentation de votre propre couche DAO est vraiment une gueule de bois de l'architecture J2EE très pauvre d'il y a 15 ans, mais beaucoup de gens se sentent toujours obligés 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 de service et d'un DAO, mais vous n'avez qu'à écrire la couche de service.
Je mets généralement tout le code spécifique à la base de données (requêtes) dans les DAO et la gestion des transactions et la logique métier dans les services. Cela permet aux méthodes de service d'appeler des méthodes sur plusieurs dao et de les garder toutes dans la même transaction. À mon avis, cela permet une meilleure réutilisation du code entre les dao.
J'ai constaté que la couche de service ajoute une complexité inutile dans la plupart des cas. En théorie, il faut éviter d'avoir une logique d'entreprise dans la couche dao, mais à la fin, cela ne fait que créer de la confusion, même certaines personnes ont refusé de supprimer complètement la couche dao car elles estiment que cela n'ajoute pas de 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'entreprise, alors oui, c'est une bonne idée. Dans quelle mesure est-il essentiel de créer une couche de service?