Нужен более глубокий пример шаблона репозитория и внедрения зависимостей

Question

Пройдя несколько уроков на asp.net mvc, появился шаблон репозитория, и пример был с одной таблицей, таблицей обедов. По сути, установка состояла в том, чтобы создать интерфейс, а затем конкретный класс, который реализовал интерфейс и запрограммировал интерфейс в классе контроллера. Интерфейс имеет ваши типичные грубые методы. Нужно ли создавать интерфейс для каждого типа, если вы собираетесь использовать этот шаблон. Например, был метод GetList с типом Dinner. Что делать, если у вас есть 10 различных типов, которые вам нужны для выполнения функции crud? означает ли это 10 интерфейсов с 10 конкретными классами только для того, чтобы иметь возможность переключать технологию БД в будущем? Я пытаюсь выяснить, как применить этот шаблон к стандартной трехуровневой архитектуре (Уровень объектов, Уровень бизнес-логики, Уровень доступа к данным).

Спасибо.

Answer 1

Так я обычно делаю в своих реализациях.

Общий интерфейс IEntityRepository, который определяет вашу базовую структуру CRUD. В моих реализациях я определяю следующие члены:

1. Вставить
2. Обновление
3. Удалить
4. Получить
5. GetPaged
6. GETALL
7. Find (этот использует построитель предикатов для построения предложения where)

Я создаю другой интерфейс IMyentityRepository, который наследует IEntityRepository. Это позволяет мне добавлять любые элементы, связанные с сущностью, и при этом иметь возможность использовать DI, когда мне это нужно. Затем я создаю свой запечатанный класс MyentityRepository, который наследует IMyentityRepository и реализует все члены.

Когда вы используете Dependency Injection, вы можете зарегистрировать свой интерфейс (IMyentityRepository) для конкретного типа MyentityRepository.

В моем случае, я на самом деле не закончил. Я создал сервисный слой поверх хранилища, чтобы инкапсулировать его и показать его в более общем виде. Например, допустим, вы хотите создать учетную запись для своего пользователя, что может потребовать больше усилий, чем просто создание записи в базе данных. В вашей службе у вас будет элемент с именем CreateUser (), который может вызывать несколько членов репозитория в своей реализации. Мой уровень обслуживания построен так же, как и мой уровень хранилища. У меня есть IEntityService для общих членов CRUD, IMyentityService для элементов, специфичных для сущности, и MyentityService для реализации. Класс MyentityService может потребовать экземпляр IMyentityService (вы можете внедрить его с выбранной платформой IoC). Уровень обслуживания также может выполнять проверку и любую бизнес-логику. Я делаю проверку в контроллерах. Ну, технически, я вызываю его своими контроллерами и получаю результат, который затем могу записать в ModelState.

Надеюсь, это немного помогло.

Answer 2

Это может быть немного сложнее, чем то, что вы ищете, но вы можете посмотреть пример приложения Northwind в S # arp Architecture .

Репозитории находятся в проекте Northwind.Core.

Также преимущество использования репозиториев и DI не в том, что вы можете переключиться на базовую технологию базы данных в будущем. Скорее, вы получаете возможность писать модульные тесты, где вы можете смоделировать и подделать службы (которые были определены интерфейсами) в тестах для классов, от которых они зависят.

Answer 3

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

Это вопрос, который я хотел бы задать, пытаясь решить:

«Должен ли каждый репозиторий поддерживать создание, чтение, обновление и удаление?»

Я решил использовать пользовательские классы репозитория, чтобы мои интерфейсы были более явными. Например, у меня есть таблицы данных поиска, которые я не разрешаю вставлять, обновлять или удалять. Репозиторий для этих таблиц содержит только методы Get. Это дает мне более чистый дизайн, но за счет немного больше работы.