Шаблон сховища та створення об'єктів DAL

Наскільки я дізнався, це IRepositoryповинно містити CRUD. Тоді ми успадковуємо це IRepositoryв наших інших інтерфейсів , як IProductі реалізувати IProductконкретний клас ProductRepository, з методами , як GetAllProducts(), Top5Products().

Ми могли б зробити те ж саме і з n-ярусною архітектурою. як, створення DAL Class Libraryі в ньому визначити клас Productз методами , як GetAllProducts(), Top5Products().

В обох DAL.Productі Repo.ProductRepositoryкласах ми инициализируем DB Contextз Entity Frameworkі запитів наших відповідних даних.

Виклик подібний в обох Repo.ProductRepositoryабо DAL.Productметодах зBLL

З огляду на ці подібності, моє питання, в чому користь Repos? Я можу зробити те ж саме з великою легкістю , використовуючи багаторівневі архітектури з ( Controller, BLL Class Library, DAL Class Library).

Я розумію:

• DAL (рівень доступу до даних) позначає шар у вашому програмному забезпеченні, який відповідає вашій технології збереження та логіці вашої програми. Його мета - тримати проблеми доступу до даних окремо від решти питань, які стосуються вашої заявки. Це загальне поняття.

• Репозиторій - це концепція від DDD (Design Driven Design).

У DDD репозиторій відповідає за інкапсуляцію всіх проблем доступу до даних для даної сукупності . Це пов'язано з відповідальністю за забезпечення послідовності під час читання та запису сукупності. І це сукупність являє собою угруповання пов'язаних осіб (наприклад, Product, Storeі т.д.).

Таким чином, Репозиторій спеціально усвідомлює свою наполегливість та послідовність Агрегату. Ваш загальний DAL, швидше за все, буде складатися з конкретних сховищ

TL; DR;

• DAL - загальний термін для усунення проблем, пов'язаних із доступом до даних.
• Репозиторій - схожа, але більш конкретна концепція від DDD.
• Ваш DAL, ймовірно, буде складатися з декількох сховищ.

Ви порівнюєте два різних та взаємодоповнюючих поняття:

• Рівень доступу до даних являє собою архітектурний шар , який має намір абстрактний доступ до даних. Це не говорить про те, як має бути обмежений доступ.
• Repository є конкретним шаблоном , який належить до ДАВ (див списку моделей в кінці цього посилання ). У ньому точно сказано, як абстрагувати певний доступ до даних: пропонуючи збірник, схожий на інтерфейс до сховища даних.

DAL у вашому прикладі

Цікаво, що у вашому прикладі бібліотеки класів, DAL.Productсхоже, є сховищем. Тож нормально, що ви насправді не бачите різниці: з точки зору впровадження це те саме (у цьому конкретному випадку).
Але це не обов'язково; DAL може бути реалізований інакше, наприклад:

• активні записи, які спираються на рівень абстракції бази даних.
• анемічні об’єкти домену (увага, анти-шаблон!), отримані з шлюзу даних рядків
• або, чому б ні, доменні об'єкти, отримані від різних об'єктів запиту, де кожен запит реалізував би певний спосіб отримання об'єкта
• сховища
• суміш усіх цих

Що відрізняється для сховища

Концепція сховища не залежить від архітектурної моделі та реалізації. Не потрібно думати про шари чи базу даних. Все, що вам потрібно знати, коли ви розробляєте свій домен, - це те, що ваші об’єкти знаходяться в сховищах, які представляють собою особливий вид колекціонування, який пропонує наполегливість. Це робить їх дуже придатними для розробки домену та пояснює, чому вони є ключовим елементом дизайну, керованого доменом .

У DDD у сховищах є ще кілька правил, яких слід дотримуватися: вони надають доступ до агрегатів (незалежна сутність або група пов'язаних сутностей, залежних від сукупного кореня), і існує одне сховище на сукупність.