Должен быть слой сервиса в Asp.net в MVC?

должен ли быть уровень обслуживания в Asp.net MVC между контроллером и репозиторием? Поскольку репозиторий существует только для доступа к данным. Некоторая бизнес-логика просачивается в контроллер. Это может создать проблему, если та же операция используется classic Asp.Net клиент, как мы должны дублировать логику в контроллере.

8
asp.net asp.net-mvc domain-driven-design nhibernate repository-pattern

6 ответов

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

для простых архитектур, построенных с нуля, это может быть перебор.

2

Если вы следуете за доменным дизайном до буквы, вы обнаружите, что есть 3 вида услуг (вы не любите перегруженные термины?).

  • Доменных Служб: инкапсулирует бизнес-логику, которая естественным образом не вписывается в объект домена и не является типичными операциями CRUD - они принадлежат хранилище.
  • Услуги Приложение: используется внешними потребителями для разговора с вашей системой (подумай!--14-->Веб-Служб). Если потребителям нужен доступ к операциям CRUD, они будут выставлены здесь (но обрабатываются соответствующим хранилище)
  • Услуги Инфраструктуры: используется для абстрактных технических проблем (например, MSMQ, поставщик электронной почты и т. д.)

звучит, как вам нужно Доменных Служб чтобы инкапсулировать / поделиться своей бизнес-логикой.

надеюсь, что это поможет!

10

TBH, я пошел в обоих направлениях. Моя текущая перспектива заключается в том, что репозиторий is служба, это просто служба, у которой есть работа по обработке CRUD ops для агрегатного корня домена. теперь, если вы "репозитории" напрямую сопоставлены 1:1 с вашими сущностями (и, следовательно, не репозитории, а DAOs), тогда я мог бы увидеть аргумент. Но обычно я добавляю слои абстракции по мере необходимости, но не до тех пор, пока не доказано, что они нужны для данного приложения. В противном случае, вы переинженер.

4

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

3

Я немного поэкспериментировал с этим. Приложение, которое я создавал, было довольно грубым, и мой сервисный уровень в конечном итоге показал почти те же интерфейсы, что и мои репозитории. Кроме того, большинство вызовов службы не добавляли никакой дополнительной логики поверх РЕПО, они были просто сквозными методами. Единственное место, где сервис layer сделал что-нибудь во время обновления или вставки новой записи. я решил, что в системе на основе CRUD уровень обслуживания вызвал больше трение, чем добавленная стоимость. В конце концов я расширил классы бизнес-модели, чтобы логика обслуживания была представлена как операции против модели, таким образом, сохраняя мои методы контроллера сухими и чистыми.

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

3

Мне нравится иметь репозитории непосредственно в контроллере в большинстве случаев и делать сервис, где я чувствую, что он протекает. Я пытаюсь иметь богатые объекты домена, но в тех случаях, когда логика не вписывается в классы домена, я создаю сервис.

1