Шаблон репозитория против создания объекта 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 (Domain Driven Design).

В DDD Репозиторий отвечает за инкапсуляцию всех проблем доступа к данным для данного Агрегата . Это связано с необходимостью обеспечения согласованности во время чтения и записи Агрегата. А Агрегат - это группа связанных сущностей (например Product, Storeи т. Д.).

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

TL; DR;

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

Вы сравниваете два разных и взаимодополняющих понятия:

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

DAL в вашем примере

Интересно, что в вашем примере библиотеки классов, DAL.Productпохоже, хранилище. Поэтому нормально, что вы на самом деле не видите разницы: с точки зрения реализации это то же самое (в данном конкретном случае).
Но это не обязательно; DAL может быть реализован по-другому, например:

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

Чем отличается репозиторий

Концепция хранилища не зависит от архитектурной модели и реализации. Вам не нужно думать о слоях или базе данных. Все, что вам нужно знать, когда вы разрабатываете свой домен, это то, что ваши объекты находятся в репозиториях, которые представляют собой особый вид коллекции, которая предлагает постоянство. Это делает их очень подходящими для проектирования доменов и объясняет, почему они являются ключевым элементом доменного дизайна .

В DDD к хранилищам предъявляются еще несколько правил: они предоставляют доступ к агрегатам (независимому объекту или группе связанных объектов, зависящих от корня агрегата), и для агрегата существует один репозиторий.