Шаблон репозитория против создания объекта DAL

9

Насколько я узнал, 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).

М. Арслан
источник
@Neil Я думаю, что OP знаком с DAL и спрашивает, являются ли репозитории просто другими интерфейсами для выполнения тех же самых задач или более того
Christophe
@ Кристоф точно, я запутался в этом. Если мы могли бы сделать то же самое в DAL, зачем использовать шаблон репо?
М. Арслан

Ответы:

7

Мое понимание таково:

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

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

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

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

TL; DR;

  • DAL - это общий термин для абстрагирования от проблем доступа к данным.
  • Репозиторий - это похожая, но более конкретная концепция DDD.
  • Ваш DAL, скорее всего, будет состоять из нескольких репозиториев.
MetaFight
источник
4
Репозиторий также является термином, который более широко используется вне DDD для обозначения коллекции объектов в памяти, которая отражает записи базы данных. В этом контексте он находится между DAL и уровнем бизнес-логики. См. Martinfowler.com/eaaCatalog/repository.html
Роберт Харви,
Почему все пытаются отдать должное DDD?
TheCatWhisperer
1
Сегодня я узнал: P
MetaFight
2

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

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

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

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

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

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

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

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

Christophe
источник