Quelle est la différence entre les modèles DAO et Repository?
Quelle est la différence entre les modèles DAO (Data Access Objects) et les modèles de référentiel? Je développe une application utilisant Enterprise Java Beans (EJB3), Hibernate ORM comme infrastructure, ainsi que la conception pilotée par le domaine (DDD) et le développement piloté par le test (TDD) comme techniques de conception.
DAO est une abstraction de persistance des données.Repository est une abstraction de ne collection d'objets.
DAO serait considéré comme plus proche de la base de données, souvent centré sur une table.Repository serait considéré comme plus proche du domaine, ne s’agissant que de racines agrégées.
Repository pourrait être implémenté en utilisant DAO ', mais vous ne feriez pas l'inverse.
De plus, un Repository est généralement une interface plus étroite. Ce devrait être simplement une collection d'objets, avec un Get(id), Find(ISpecification), Add(Entity).
Une méthode telle que Update est appropriée sur un DAO, mais pas un Repository - lors de l'utilisation d'un Repository, les modifications apportées aux entités seraient généralement suivies par UnitOfWork séparé.
Il semble courant de voir des implémentations appelées Repository qui est en réalité plus d'un DAO, et je pense donc qu'il existe une certaine confusion quant à la différence qui existe entre elles.
OK, pense que je peux mieux expliquer ce que j'ai mis dans les commentaires :). Vous pouvez donc voir les deux comme identiques, bien que DAO soit un modèle plus flexible que Repository. Si vous souhaitez utiliser les deux, vous utiliserez le référentiel dans vos DAO-s. Je vais expliquer chacun d'eux ci-dessous:
DÉPÔT:
C'est un référentiel d'un type d'objet spécifique - il vous permet de rechercher un type d'objet spécifique ainsi que de le stocker. Habituellement, il ne gère qu'un seul type d'objets. Par exemple. AppleRepository vous permettrait de faire AppleRepository.findAll(criteria) ou AppleRepository.save(juicyApple). Notez que le référentiel utilise les termes du modèle de domaine (pas les termes de la base de données - rien n’est lié à la façon dont les données sont conservées où que ce soit).
Un référentiel stockera probablement toutes les données dans la même table, alors que le modèle ne l'exige pas. Le fait qu'il ne traite qu'un type de données, cependant, le rend logiquement connecté à une table principale (si utilisé pour la persistance de la base de données).
DAO - objet d'accès aux données (en d'autres termes - objet utilisé pour accéder aux données)
Un DAO est une classe qui localise des données pour vous (il s’agit principalement d’un Finder, mais il est généralement utilisé pour stocker également les données). Le modèle ne vous oblige pas à stocker des données du même type, vous pouvez donc facilement avoir un DAO qui localise/stocke les objets associés.
Par exemple. vous pouvez facilement avoir UserDao qui expose des méthodes comme
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
Tous ceux qui sont liés à l'utilisateur (et à la sécurité) peuvent être spécifiés sous le même DAO. Ce n'est pas le cas pour le référentiel.
Finalement
Notez que les deux modèles ont vraiment la même signification (ils stockent des données et en abstinent l’accès; ils sont tous deux plus proches du modèle de domaine et ne contiennent pratiquement aucune référence de base de données), mais leur utilisation peut être légèrement différente, DAO étant un peu plus flexible/générique, tandis que Repository est un peu plus spécifique et restrictif pour un type uniquement.
DAO et le modèle de référentiel sont des moyens d'implémenter la couche d'accès aux données (DAL). Commençons par DAL.
Les applications orientées objet qui accèdent à une base de données doivent avoir une logique pour gérer l'accès à la base de données. Afin de garder le code propre et modulaire, il est recommandé d'isoler la logique d'accès à la base de données dans un module séparé. En architecture en couches, ce module est DAL.
Jusqu'à présent, nous n'avons parlé d'aucune implémentation particulière: seulement un principe général selon lequel la logique d'accès à la base de données est intégrée dans un module séparé.
Maintenant, comment pouvons-nous appliquer ce principe? Eh bien, un modèle connu pour implémenter cela, en particulier avec des frameworks comme Hibernate, est le modèle DAO.
Le modèle DAO est un moyen de générer un DAL, chaque entité de domaine ayant généralement son propre DAO. Par exemple, User et UserDao, Appointment et AppointmentDao, etc. Un exemple de DAO avec Hibernate: http://gochev.blogspot.ca/ 2009/08/hibernate-generic-dao.html .
Alors quel est le modèle de référentiel? Comme DAO, le modèle de référentiel est également un moyen de réaliser DAL. Le principal aspect du modèle de référentiel est que, du point de vue du client/utilisateur, il devrait ressembler ou se comporter comme une collection. Se comporter comme une collection ne signifie pas qu'elle doit être instanciée comme Collection collection = new SomeCollection(). Au lieu de cela, cela signifie qu'il devrait prendre en charge des opérations telles que l'ajout, la suppression, le contenu, etc. C'est l'essence du modèle de référentiel.
En pratique, par exemple dans le cas d’utilisation de Hibernate, le modèle de référentiel est réalisé avec DAO. C'est une instance de DAL qui peut être à la fois une instance de modèle DAO et un modèle de référentiel.
Le modèle de référentiel n’est pas nécessairement quelque chose que l’on construit sur DAO (comme certains pourraient le suggérer). Si les DAO sont conçus avec une interface prenant en charge les opérations mentionnées ci-dessus, il s'agit d'une instance de modèle de référentiel. Pensez-y. Si les DAO fournissent déjà un ensemble d'opérations de type collection, alors quel est le besoin d'une couche supplémentaire par-dessus?
Franchement, cela ressemble à une distinction sémantique, pas à une distinction technique. La phrase Data Access Object ne fait pas référence à une "base de données" du tout. Et, bien que vous puissiez le concevoir pour être centré sur la base de données, je pense que la plupart des gens considéreraient cela comme un défaut de conception.
L'objectif de DAO est de masquer les détails d'implémentation du mécanisme d'accès aux données. En quoi le modèle de référentiel est-il différent? Autant que je sache, ça ne l'est pas. Dire un référentiel est différent à un DAO parce que vous avez affaire à/retournez une collection d'objets ne peut pas être juste; Les DAO peuvent également renvoyer des collections d'objets.
Tout ce que j'ai lu sur le modèle de référentiel semble reposer sur cette distinction: mauvaise conception DAO vs bonne conception DAO (modèle de conception de référentiel).
Le référentiel est un terme plus abstrait, orienté vers le domaine, qui fait partie de la conception dirigée par le domaine. Il fait partie de la conception de votre domaine et d’un langage commun. DAO est une abstraction technique pour la technologie d’accès aux données. Les données.
vérifier ces liens:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/http://fabiomaulo.blogspot.com/2009/09/repository-or -dao-repository.html
La principale différence est qu'un référentiel gère l'accès aux racines d'agrégat dans un agrégat, tandis que DAO gère l'accès aux entités. Par conséquent, il est courant qu'un référentiel délègue la persistance réelle des racines agrégées à un DAO. De plus, comme la racine agrégée doit gérer l'accès des autres entités, elle peut avoir besoin de déléguer cet accès à d'autres DAO.
Les référentiels ne sont que des DAO bien conçus.
ORM est centré sur la table mais pas DAO.
Il n'est pas nécessaire d'utiliser plusieurs DAO dans un référentiel, étant donné que DAO lui-même peut faire exactement la même chose avec les référentiels/entités ORM ou tout fournisseur DAL, peu importe où et comment une voiture est conservée 1 table, 2 tables, n tables, une demi-table, une service Web, une table et un service Web, etc. Les services utilisent plusieurs référentiels DAO.
Mon propre DAO, disons que CarDao s’occupe uniquement de Car DTO, je veux dire, ne prend que Car DTO en entrée et ne renvoie que des collections de voitures DTO ou de voitures DTO en sortie.
Donc, tout comme Repository, DAO est en fait un IoC, pour la logique métier, permettant aux interfaces de persitence de ne pas être intimidé par des stratégies de persitence ou des legs. DAO englobe à la fois la stratégie de persistance et fournit l'interface de persistance liée au domaine. Le référentiel est juste un autre mot pour ceux qui n'ont pas compris ce qu'est un DAO bien défini.
Essayez de déterminer si le modèle DAO ou le référentiel s’applique le mieux à la situation suivante: Imaginez que vous souhaitez fournir une API d’accès aux données uniforme pour un mécanisme persistant pour différents types de sources de données telles que SGBDR, LDAP, OODB, référentiels XML et. fichiers plats.
Reportez-vous également aux liens suivants, si vous êtes intéressé:
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
DAO fournit une abstraction sur les fichiers de base de données/données ou tout autre mécanisme de persistance afin que la couche de persistance puisse être manipulée sans connaître les détails de son implémentation.
Alors que dans les classes de référentiel, plusieurs classes DAO peuvent être utilisées dans une seule méthode de référentiel pour effectuer une opération du point de vue de l'application. Ainsi, au lieu d'utiliser plusieurs couches DAO au niveau de la couche de domaine, utilisez un référentiel pour le faire. Le référentiel est une couche qui peut contenir une logique d'application comme: Si les données sont disponibles dans le cache en mémoire, récupérez-les du cache sinon, récupérez les données du réseau et stockez-les dans le cache en mémoire pour la prochaine fois. récupération.
en une phrase très simple: la différence significative étant que les référentiels représentent des collections, alors que les DAO sont plus proches de la base de données, souvent beaucoup plus centrés sur les tables.