Можно ли ввести слишком много репозиториев в контроллер? - PullRequest
Новая
       32

Можно ли ввести слишком много репозиториев в контроллер?

4 голосов
/ 15 сентября 2011

У меня есть первое большое решение, над которым я работаю с использованием MVC3.Я использую ViewModels, AutoMapper и DI.

Чтобы создать мои ViewModels для некоторых более сложных операций редактирования / создания, я добавляю 10 или около того
репозиториев.Для всех, кроме одного из репозиториев, они есть только для того, чтобы получить данные для заполнения списка выбора в ViewModel, поскольку я просто получаю ассоциированные объекты FK и т. Д.

Я видел, что упоминалось, что инъекция большого количестваРепозитории это плохая практика, и я должен рефакторинг.Сколько стоит многим?это многим?Как я должен рефакторинг?Должен ли я создать специальный сервис, который возвращает списки выбора и т. Д.?

Просто для примера приведу конструктор для моего контроллера RequirementsAndOffer 

       public RequirementsAndOfferController(
IdefaultnoteRepository defaultnoteRepository, 
IcontractformsRepository contractformsRepository, 
IperiodRepository periodRepository, 
IworkscopeRepository workscopeRepository, 
IcontactRepository contactRepository, 
IlocationRepository locationRepository, 
IrequirementRepository requirementRepository, 
IContractorRepository contractRepository, 
IcompanyRepository companyRepository, 
IcontractRepository contractRepository, 
IrequirementcontracttypeRepository requirementcontracttypeRepository, 
IoffercontractRepository offercontractRepository)

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

Обновление Общие мысли и обновления.Я был поощрен, чтобы рассмотреть эту проблему статьей блога Марка Симэнна на чрезмерном введенииМеня интересовали именно репозитории и почему я должен был ввести это число.Я думаю, учитывая мой дизайн, я явно не использую один репозиторий для каждого совокупного корня (согласно DDD).

У меня есть, например, автомобили, и у автомобилей есть контракты на прокат, а контракты на прокат имеют периоды аренды.

Я создавал хранилище для автомобилей, договоров найма и периодов найма.Так что это создавало 3 репозитория, когда я думаю, что должен быть только один.договоры аренды и сроки не могут существовать без автомобилей.Поэтому я сократил некоторые репозитории таким образом.

У меня все еще остаются некоторые сложные формы (клиент требует эти большие формы), которые требуют наличия нескольких репозиториев в контроллере.Это может быть потому, что я недостаточно рефакторинг.Насколько я вижу, мне понадобятся отдельные репозитории для получения списков выбора.

Я рассматриваю варианты создания какой-либо службы, которая предоставит все нужные мне списки выбора.Это хорошая практика / плохая практика?Должны ли мои услуги быть ориентированы только на совокупные корни?В этом случае было бы неправильно иметь одну службу, предоставляющую выбор.Тем не менее, кажется, что выборка - это один и тот же тип вещи, и группировка их вместе привлекательна в некоторых отношениях.

Казалось бы, мой вопрос похож на как разобраться с конструктором над инъекцией в сети

Я думаю, что сейчас больше ищуКонкретный совет о том, хорош ли сервис списка выбора.

Любой совет приветствуется.

1 Ответ

2 голосов
/ 15 сентября 2011

У вас правильная идея, начиная с шаблона репозитория.В зависимости от того, как вы используете свои репозитории, я полностью понимаю, как вы можете получить много (может быть, даже 1 на таблицу базы данных).

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

Бизнес-уровень

Этот уровень может состоять из бизнес-объектов, которые инкапсулируют одно или несколько намерений ваших моделей представления (и по сути представлений).Вы не описали ни один из своих доменов, но, возможно, бизнес-объект для Users может включать некоторые методы CRUD.Тогда ваши модели представлений будут полагаться на эти бизнес-объекты, а не на прямой вызов методов репозитория.Возможно, вы уже догадались, что рефакторинг переместит вызовы методов репозитория в бизнес-объекты

Сервисный уровень

Сервисный уровень может даже использовать некоторые из бизнес-объектов, описанных выше, но, возможно, вы можете разработатьнекоторый тип протокола / системы / стандарта обмена сообщениями для связи между вашим веб-приложением и, возможно, службой WCF, работающей на сервере, для управления каким-либо состоянием.

Это не самый описательный из примеров, но я надеюсь, что это поможет с очень высоким уровнем просмотра параметров рефакторинга.

...