Один или несколько классов репозитория?
моя база данных относительно небольшая, 8 таблиц, каждая с менее чем 5 столбцами. Я использую EF. Я создал один класс репозитория, но теперь, когда я думаю, что это может быть неправильный способ его использования. Должен ли я иметь отдельный класс репозитория для каждого из моих контроллеров? Допустим, у меня есть продукты, пользователи, единороги, было бы хорошо иметь один класс репозитория для работы со всеми из них и создавать экземпляры в каждом из этих контроллеров, или я должен создать отдельный класс репозитория для каждого из них эти?
3 ответов
одним из ключевых понятий DDD является совокупный корень - это сущность "верхнего уровня", через которую вы управляете целыми наборами связанных сущностей.
например, в розничном сценарии "заказ" будет агрегированным корнем, через который вы можете получить доступ к самому заказу, списку OrderItems (т. е. продукт + сумма + модификаторы, такие как скидки), BillingAddress, ShippingAddress и PaymentMethod. В каждом из них, тесно связанные с тем, что у них нет причин существовать вне рамок заказа.
каждый совокупный корень должен иметь репозиторий, который несет ответственность за сохранение всего подграфа объектов под корнем. Таким образом, в приведенном выше примере вам не нужен или не нужен репозиторий для OrderItems, который позволяет получить доступ к элементам заказа независимо; вместо этого вы должны реализовать один OrdersRepository, который имеет дело с заказами и всеми их субкомпонентами как единое целое.
в зависимости от в вашей конкретной модели домена может потребоваться один или несколько репозиториев, но, конечно, не по одному типу сущности. Ключевой вопрос, который нужно задать при поиске aggregate roots: "имеет ли эта сущность свою собственную идентичность и жизненный цикл?"Заказы делать, строк orderitems не.
подумайте о доменном дизайне, и с учетом этого вы разделяете логическую структуру своего проекта не только как классы, но и как Домены, что означает, что все операции связаны с Product находятся в ProductsController и в ProductsRepository, поэтому я предпочитаю много репозиториев, каждый из которых оснащен операциями для решения некоторых аспектов вашего проекта.
не все аспекты могут нуждаться в репозитории, но это то, что вы решаете.
Я не думаю, что репоистора на объект-хорошая идея, а скорее репозиторий на службу, если это имеет смысл.
например, я бы не пошел и не сделал CategoriesRepository или CarsRepository, если мое основное приложение сосредоточено на пользователях.