Как я могу управлять шаблоном общего репозитория, когда работы разных сущностей сильно отличаются друг от друга?

Я новичок в шаблоне репозитория.

Когда я управляю CRUD операциями нескольких объектов (таких как клиенты, заказы и т. Д.), Тогда это прекрасно. Я создаю интерфейс, я создаю общий repository. И это служит моей цели, потому что операция CRUD является общей для них.

Мой вопрос:

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

Как я могу управлять шаблоном общего репозитория, когда работы разных сущностей сильно отличаются друг от друга ?

Это основная проблема с шаблоном Generic Repository; поэтому он считается анти- паттерном .

Я читал это здесь :

Независимо от того, какой умный механизм я пытался, я всегда оказывался в той же проблеме: repository является частью моделируемого домена, и этот домен не является общим. Не каждый объект может быть удален, но не каждый объект может быть добавлен, а не каждый объект имеет repository. Запросы сильно различаются; API-интерфейс репозитория становится таким же уникальным, как и сам объект.

Почему общий repository является анти-шаблоном?

  1. Репозиторий является частью моделируемого домена, и этот домен не является общим.
    • Не каждый объект может быть удален.
    • Не каждый объект может быть добавлен
    • Не каждый объект имеет repository.
    • Запросы сильно различаются; API-интерфейс репозитория становится таким же уникальным, как и сам объект.
    • Для GetById() типы идентификаторов могут быть разными.
    • Невозможно обновить определенные поля (DML).
  2. Механизм общих запросов является обязанностью ORM.
    • Большинство ORM демонстрируют реализацию, которая очень похожа на общий repository.
    • Хранилища должны реализовывать СПЕЦИФИЧЕСКИЕ запросы для сущностей, используя общий механизм запросов, открытый ORM.
  3. Работа с составными клавишами невозможна.
  4. В любом случае, он протекает в DAL-логике.
    • Критерий предикации, если вы принимаете параметр как параметр, должен предоставляться с уровня сервиса. Если это специфический class ORM, он теряет ORM в Services.

Я предлагаю вам прочитать эти ( 1 , 2 , 3 , 4 , 5 ) статьи, объясняющие, почему общий repository является anit-образцом.

Лучший подход:

  1. Пропустить общий repository. Реализовать конкретные репозитории.
  2. Используйте Generic Repository как абстрактный базовый repository. Извлеките из него все конкретные хранилища.

В любом случае не выставляйте общий repository вызывающему коду. Кроме того, не подвергайте IQueryable из конкретных репозиториев.

Давайте будем гением компьютера.