Repository-Muster vs DAL-Objekterstellung

Soweit ich gelernt habe, IRepositorysollte das enthalten CRUD. Dann erben wir dies IRepositoryin unseren anderen Interfaces like IProductund implementieren IProductkonkrete Klassen ProductRepositorymit Methoden wie GetAllProducts(), Top5Products().

Dasselbe könnten wir auch mit der n-Tier-Architektur tun. wie, Erstellen DAL Class Libraryund definieren Sie darin eine Klasse Productmit Methoden wie GetAllProducts(), Top5Products().

In beiden DAL.Productund Repo.ProductRepositoryKlassen , die wir initialisieren DB Contextvon Entity Frameworkund unsere relevanten Daten abfragen.

Der Aufruf ist in beiden Repo.ProductRepositoryoder DAL.ProductMethoden von ähnlichBLL

Angesichts dieser Ähnlichkeiten meine Frage, was ist der Nutzen von Repos? Ich kann das gleiche mit viel Leichtigkeit tun n-Tier - Architekturen mit der Verwendung von ( Controller, BLL Class Library, DAL Class Library).

Mein Verständnis ist:

• DAL (Data Access Layer) bezieht sich auf eine Schicht in Ihrer Software, die zwischen Ihrer Persistenztechnologie und Ihrer Anwendungslogik liegt. Der Zweck besteht darin, die Bedenken hinsichtlich des Datenzugriffs von den übrigen Bedenken Ihrer Anwendung zu trennen. Es ist ein allgemeines Konzept.

• Repository ist ein Konzept von DDD (Domain Driven Design).

In DDD ist ein Repository dafür verantwortlich, alle Datenzugriffsprobleme für ein bestimmtes Aggregat zu kapseln . Dies geht mit der Verantwortung einher, die Konsistenz beim Lesen und Schreiben des Aggregats sicherzustellen. Und ein Aggregat ist eine Gruppe von verwandten Entitäten (zB Product, Storeusw.).

So ist ein Repository speziell sich seine Aggregate Beharrlichkeit und Beständigkeit betrifft. Ihr allgemeiner DAL wird höchstwahrscheinlich aus bestimmten Repositories bestehen

TL; DR;

• DAL ist ein allgemeiner Begriff für die Abstraktion von Datenzugriffsproblemen.
• Repository ist ein ähnliches, aber spezifischeres Konzept von DDD.
• Ihr DAL wird wahrscheinlich aus mehreren Repositories bestehen.

Sie vergleichen zwei verschiedene und sich ergänzende Konzepte:

• Die Datenzugriffsschicht ist eine Architekturschicht, die den Zugriff auf Daten abstrahieren soll. Es heißt nicht, wie der Zugang abstrahiert werden soll.
• Das Repository ist ein bestimmtes Muster, das zur DAL gehört (siehe Liste der Muster am Ende dieses Links ). Es wird genau beschrieben, wie ein bestimmter Zugriff auf Daten abstrahiert werden kann: indem eine sammlungsähnliche Schnittstelle zum Datenspeicher angeboten wird.

Das DAL in Ihrem Beispiel

Interessanterweise DAL.Productscheint in Ihrem Beispiel der Klassenbibliothek ein Repository zu sein. Es ist also normal, dass Sie keinen wirklichen Unterschied sehen: Aus Sicht der Implementierung ist es dasselbe (in diesem speziellen Fall).
Aber es muss nicht; Ein DAL könnte anders implementiert werden, zum Beispiel:

• aktive Datensätze , die auf einer Datenbankabstraktionsschicht basieren.
• anämische Domänenobjekte (Aufmerksamkeit, Anti-Pattern!), die von einem Zeilendaten-Gateway erhalten wurden
• oder, warum nicht, Domänenobjekte, die von verschiedenen Abfrageobjekten erhalten wurden, wobei jede Abfrage eine bestimmte Methode zum Abrufen des Objekts implementieren würde
• Repositories
• eine Mischung aus all diesen

Was ist anders für das Repository

Das Konzept des Repositorys ist unabhängig vom Architekturmodell und der Implementierung. Sie müssen nicht in Ebenen oder Datenbanken denken. Alles, was Sie beim Entwerfen Ihrer Domain wissen müssen, ist, dass sich Ihre Objekte in Repositorys befinden, die eine besondere Art von Sammlung darstellen, die Beständigkeit bietet. Dies macht sie sehr gut für das Domain-Design geeignet und erklärt, warum sie ein Schlüsselelement des Domain Driven Design sind .

In DDD müssen die Repositorys einige weitere Regeln beachten: Sie ermöglichen den Zugriff auf Aggregate (eine unabhängige Entität oder eine Gruppe verwandter Entitäten, die von einem Aggregatstamm abhängig sind), und es gibt ein einzelnes Repository pro Aggregat.