Правильно ли мы используем шаблон хранилища?


14

Мы используем несколько отдельных классов с суффиксами -repositoryдля извлечения данных из базы данных; для каждой таблицы свой репозиторий.

Например, у нас есть customerrepositoryкласс, который имеет все виды методов для поиска клиентов, и класс, который имеет все виды vacancyrepositoryметодов для поиска вакансий.

У меня есть два вопроса об этом способе ведения дел:

  1. Как насчет получения данных, которые охватывают несколько таблиц? Например, у меня есть экран, который показывает всех клиентов, которые еще не создали вакансию. Могут ли customerrepositoryметоды использования из vacancyrespositoryили оба хранилища возвращать результаты, и есть ли класс в иерархии выше (назовем его a dataservice), который получает результаты из обоих хранилищ и объединяет их в 1 результат?

  2. сколько логики может обработать такой репозиторий?
    Я думаю, что это нормально для реализации 'where active == true' в хранилище для извлечения только активных записей, или даже эта простая логика должна обрабатываться классом выше в иерархии (назовем это a dataservice)?

Вот пример, с которым я столкнулся:

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

Сейчас у нас есть 3 разных репозитория для этих таблиц.

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

Или есть тот, questionlistdataserviceкоторый знает, какие репозитории использовать?

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


1
Обычно при множественном доступе к таблице доминирующая таблица определяется таблицей записи, которая должна существовать до того, как запрос ее получит. В LEFT OUTER JOIN это будет первая упомянутая таблица, а в RIGHT OUTER JOIN - вторая.
Нил

Ответы:


15

Репозиторий возвращает доменные объекты и построен поверх слоев отображения. Для очень простых доменов доменные объекты и таблицы базы данных могут быть практически одинаковыми.

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

Пример: в вашей базе данных есть таблицы для персоны и адреса. В вашем приложении адрес домена не является собственной сущностью, это просто свойство Person. В этом случае у вас не будет PersonRepository и AddressRepository. У вас просто есть PersonRepository. Домен не должен беспокоиться о том, как данные домена сохраняются. Эти обязанности находятся в слое за хранилищем.

Из вашего примера может показаться, что вы на самом деле имеете DAO и только что назвали их Repositories.


Таким образом, при создании хранилища у меня также может быть шлюз данных таблиц на один уровень глубже, и наши хранилища на самом деле являются TDG.
Мишель

1
Вы могли бы, но взвесить стоимость и выгоды. Не допускайте, чтобы DAO и репозитарии были разделены по принципу «многоуровневого кодирования». Делайте то, что наиболее читабельно в этом случае. Разделение и результирующий уровень абстракции могут быть полезны, если ваши репозитории обычно много рекомбинируют данные в DAO.
Михай Данила
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.