Моя база данных относительно небольшая, 8 таблиц, каждая из которых имеет менее 5 столбцов. Я использую EF. Я создал единственный класс репозитория, но теперь, когда я думаю, что это может быть неправильный способ его использования. Должен ли я иметь отдельный класс репозитория для каждого из моих контроллеров? Допустим, у меня есть продукты, пользователи, единороги, было бы хорошо, чтобы один класс репозитория работал со всеми этими и создавал экземпляр в каждом из этих контроллеров, или я должен создать отдельный класс репозитория для каждого из них?
Один или несколько классов репозитория?
Ответ 1
Одной из основных концепций DDD является совокупный корень - это сущность "верхнего уровня", через которую вы управляете целыми наборами связанных объектов.
Например, в розничном сценарии "Заказ" представляет собой совокупный корень, через который вы можете получить доступ к самому Заказу, списку OrderItems (например, Product + Amount + модификаторы, такие как скидки), BillingAddress, ShippingAddress и PaymentMethod. Каждый из них тесно связан с самим заказом, до того момента, когда у них нет причин существовать вне сферы действия заказа.
Каждый корень агрегата должен иметь репозиторий, которому принадлежит ответственность за сохранение всего подграфа объектов под корнем. Таким образом, в приведенном выше примере вам не нужен или нужен репозиторий для OrderItems, который позволяет независимо обращаться к элементам заказа; вместо этого вы должны реализовать единый OrdersRepository, который имеет дело с Orders и всеми их подкомпонентами как единое целое.
В зависимости от вашей конкретной модели домена вам может понадобиться один или несколько репозиториев, но, конечно, не один тип сущности. Ключевой вопрос, который нужно задать при поиске совокупных корней, - "имеет ли этот объект свою собственную идентификацию и жизненный цикл?" Заказы, OrderItems нет.
Ответ 2
Think Domain-Driven Design, и имея это в виду, вы разделяете логическую структуру своего проекта не только на классы, но также как и домены, что означает, что все операции связаны с Product, расположены в пределах ProductsController и, следовательно, в пределах ProductsRepository, поэтому я предпочитаю много репозиториев, каждый из которых оснащен операциями для решения некоторых аспектов вашего проекта.
Не все аспекты могут нуждаться в репозитории, но это то, что вы решаете.
Ответ 3
Я не думаю, что репоистория на сущность - хорошая идея, а скорее репозиторий на услугу, если это имеет смысл.
например, я бы не пошел и не создавал КатегорииRepository или CarsRepository, если основное внимание в приложении сосредоточено на Пользователях.