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

Question

Пример. В вашей базе данных есть представление SQL с именем «CustomerOrdersOnHold». Это представление возвращает отфильтрованное сочетание определенных полей данных клиента и заказа. Вам нужно получить данные из этого представления в вашем приложении. Как доступ к такому представлению вписывается в шаблон хранилища? Вы бы создали "CustomerOrdersOnHoldRepository"? Является ли представление, доступное только для чтения, такое, как это, для совокупного корня?

Answer 1

Я бы предпочел разделить репозиторий для чтения, желательно даже изменить его имя на Finder или Reader, репозиторий предназначен для использования Домена, а не для запроса данных только для чтения, вы можете обратиться к этой статье и это , которое объясняет использование отдельного хранилища форм Finder.

Я бы также рекомендовал отделить модель чтения от архитектуры модели записи. CQRS и там

Эта архитектура позволяет отделить модель чтения от модели записи даже с точки зрения хранения данных и использования источников событий.

Для промежуточного решения вы можете использовать некоторые концепции CQRS, не усложняя отделение базы данных, просто отделяя репозиторий от искателей, прочитайте это post

для образца решения такого типа (используйте ту же базу данных, но с разделителями поиска в репозиториях) отметьте этот образец

Answer 2

Ваши данные только для чтения будут считаться объектами значения в мире DDD.

Обычно я размещаю методы доступа к объектам-значениям в существующих репозиториях до тех пор, пока не будет целесообразно создать отдельный репозиторий.Это похоже на метод, который может возвращать статический список состояний для использования в форме адреса:

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}

Answer 3

Я думаю, что хорошо иметь отдельный репозиторий, такой как "CustomerOrdersOnHoldRepository".Интерфейс репозитория будет отражать тот факт, что объекты доступны только для чтения (без определения метода Save / Add / MakePersistent).

From Как написать репозиторий :

... Но есть еще одна стратегия, которая мне очень нравится: несколько хранилищ.В нашем примере заказа нет причин, по которым у нас может быть два репозитория: AllOrders и SurchargedOrders.AllOrders представляют список, содержащий каждый отдельный порядок в системе, SurchargedOrders представляет его подмножество.

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