Modèle de référentiel vs création d'objet DAL
Pour autant que je sache, le IRepository devrait contenir CRUD. Ensuite, nous héritons de ce IRepository dans nos autres interfaces comme IProductet implémentons IProductconcrete class ProductRepository, avec des méthodes comme GetAllProducts(), Top5Products().
Nous pourrions également faire de même avec une architecture à n niveaux. comme, Créer DAL Class Library et y définir une classe Product avec des méthodes comme GetAllProducts(), Top5Products().
Dans les classes DAL.Product Et Repo.ProductRepository, Nous initialisons DB Context De Entity Framework Et interrogons nos données pertinentes.
L'appel est similaire dans les deux méthodes Repo.ProductRepository Ou DAL.Product De BLL
Compte tenu de ces similitudes, ma question quel est l'avantage de Repos? Je peux faire la même chose avec beaucoup de facilité en utilisant des architectures à n niveaux avec (Controller, BLL Class Library, DAL Class Library).
Ma compréhension est:
DAL (Data Access Layer) fait référence à une couche dans votre logiciel qui se trouve entre votre technologie de persistance et votre logique d'application. Son objectif est de séparer les problèmes d'accès aux données du reste des problèmes de votre application. C'est un concept ( général .
Repository est un concept de DDD (Domain Driven Design).
Dans DDD, un Repository est responsable de l'encapsulation de tous les problèmes d'accès aux données pour un Aggregate donné. Cela implique la responsabilité d'assurer la cohérence lors des lectures et écritures de l'agrégat. Et un agrégat est un regroupement d'entités liées (par exemple, Product, Store, etc.).
Ainsi, un référentiel est spécifiquement conscient des problèmes de persistance et de cohérence de son agrégat. Votre DAL général sera très probablement composé de référentiels spécifiques
TL; DR;
- DAL est un terme général pour résumer les problèmes d'accès aux données.
- Repository est un concept similaire, mais plus spécifique, de DDD.
- Votre DAL sera probablement composé de plusieurs référentiels.
Vous comparez deux concepts différents et complémentaires:
- Data Access Layer est une couche architecturale qui a pour but d'abstraire l'accès aux données. Il ne dit pas comment l'accès doit être abstrait.
- Repository est un modèle spécifique qui appartient au DAL (voir la liste des modèles à la fin de ce lien ). Il explique exactement comment abstraire un accès spécifique aux données: en offrant une interface de type collection au magasin de données.
Le DAL dans votre exemple
Fait intéressant, dans votre exemple de bibliothèque de classes, DAL.Product semble être un référentiel. Il est donc normal que vous ne voyiez pas vraiment de différence: du point de vue de l'implémentation, c'est la même chose (dans ce cas spécifique).
Mais ce n'est pas obligatoire; Un DAL peut être implémenté différemment, par exemple:
- enregistrements actifs qui reposent sur une couche d'abstraction de base de données.
- objets du domaine anémique (attention, anti-modèle!) obtenu à partir d'une passerelle de données de ligne
- ou, pourquoi pas, des objets de domaine obtenus à partir de différents objets de requête, où chaque requête implémenterait une manière particulière de récupérer l'objet
- référentiels
- un mélange de tous ceux
Ce qui est différent pour le référentiel
Le concept de référentiel est indépendant du modèle architectural et de la mise en œuvre. Vous n'avez pas besoin de penser aux couches ou à la base de données. Tout ce que vous devez savoir lorsque vous concevez votre domaine, c'est que vos objets sont dans des référentiels qui sont un type spécial de collection qui offre de la persistance. Cela les rend très adaptés à la conception de domaine et explique pourquoi ils sont un élément clé de Domain Driven Design .
Dans DDD, les référentiels ont d'autres règles à respecter: ils donnent accès à des agrégats (une entité indépendante ou un groupe d'entités liées dépendant d'une racine d'agrégat) et il y a un seul référentiel par agrégat.