Wzorzec repozytorium a tworzenie obiektów DAL

O ile się dowiedziałem, IRepositorypowinien zawierać CRUD. Wtedy dziedziczą to IRepositoryw naszych innych interfejsów, jak IProducti realizować IProductkonkretne klasy ProductRepository, z metod, takich jak GetAllProducts(), Top5Products().

To samo możemy zrobić z architekturą n-tier. jak, tworzenie DAL Class Libraryaw nim zdefiniować klasę Productz metod, takich jak GetAllProducts(), Top5Products().

W obu DAL.Producti Repo.ProductRepositoryklas możemy zainicjować DB Contextod Entity Frameworki kwerendy nasze odpowiednich danych.

Wywołanie jest podobne w obu metodach Repo.ProductRepositorylub DAL.ProductzBLL

Biorąc pod uwagę te podobieństwa, moje pytanie, jakie są korzyści z repos? Może zrobić to samo z dużą łatwością za pomocą architektury wielowarstwowej o ( Controller, BLL Class Library, DAL Class Library).

Rozumiem:

• DAL (Data Access Layer) odnosi się do warstwy w oprogramowaniu, która znajduje się między technologią trwałości a logiką aplikacji. Jego celem jest oddzielenie problemów związanych z dostępem do danych od pozostałych problemów związanych z aplikacją. To ogólna koncepcja.

• Repozytorium to koncepcja z DDD (Domain Driven Design).

W DDD repozytorium jest odpowiedzialne za hermetyzowanie wszystkich problemów związanych z dostępem do danych dla danego agregatu . Wiąże się to z obowiązkiem zapewnienia spójności podczas odczytów i zapisów Kruszywa. A kruszywo jest grupowanie powiązanych podmiotów (np Product, Storeitp).

Dlatego repozytorium jest szczególnie świadome problemów związanych z trwałością i spójnością swojego agregatu. Twój ogólny DAL najprawdopodobniej będzie się składał z określonych repozytoriów

TL; DR;

• DAL to ogólny termin na usunięcie problemów związanych z dostępem do danych.
• Repozytorium jest podobną, ale bardziej szczegółową koncepcją z DDD.
• Twój DAL będzie prawdopodobnie składał się z kilku repozytoriów.

Porównujesz dwie różne i uzupełniające się koncepcje:

• Dostępu do danych warstwa jest warstwą architektoniczny, który zamierza abstrakcyjnego dostępu do danych. Nie mówi, jak dostęp powinien być abstrakcji.
• Repozytorium jest specyficzny wzór, który należy do DAL (patrz lista wzorów na końcu tego linku ). Mówi dokładnie, jak wyodrębnić określony dostęp do danych: oferując interfejs podobny do kolekcji magazynu danych.

DAL w twoim przykładzie

Co ciekawe, w twoim przykładzie biblioteki klas DAL.Productwydaje się być repozytorium. To normalne, że tak naprawdę nie widać różnicy: z punktu widzenia implementacji jest tak samo (w tym konkretnym przypadku).
Ale nie musi; DAL może być zaimplementowany inaczej, na przykład:

• aktywne rekordy, które opierają się na warstwie abstrakcji bazy danych.
• anemiczne obiekty domeny (uwaga, anty-wzorzec!) uzyskane z bramy danych wiersza
• lub, dlaczego nie, obiekty domeny uzyskane z różnych obiektów zapytań, w których każde zapytanie zaimplementuje określony sposób odzyskania obiektu
• repozytoria
• połączenie tych wszystkich

Czym różni się repozytorium

Koncepcja repozytorium jest niezależna od modelu architektonicznego i wdrożenia. Nie musisz myśleć o warstwach ani bazie danych. Wszystko, co musisz wiedzieć, projektując domenę, to to, że Twoje obiekty znajdują się w repozytoriach, które są szczególnym rodzajem kolekcji, która zapewnia trwałość. Dzięki temu są bardzo odpowiednie do projektowania domen i wyjaśniają, dlaczego są kluczowym elementem projektowania opartego na domenach .

W DDD repozytoria mają więcej zasad, których należy przestrzegać: dają dostęp do agregatów (niezależny byt lub grupa powiązanych podmiotów zależnych od zagregowanego katalogu głównego) i istnieje jedno repozytorium na agregat.