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

Question

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

Answer 1

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

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

Похоже, вам нужно Доменные службы для инкапсуляции / обмена вашей бизнес-логикой.

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

Answer 2

ТБХ, я пошел по этому пути. Моя текущая точка зрения заключается в том, что репозиторий - это служба, это просто служба, которая выполняет работу по обработке операций CRUD для корневого агрегата домена. теперь, если вы «репозитории» напрямую сопоставлены 1: 1 с вашими сущностями (и, следовательно, не столько с репозиториями, сколько с DAO), тогда я мог бы увидеть аргумент. Но, как правило, я добавляю слои абстракции по мере необходимости, но не до тех пор, пока не доказано, что они необходимы для данного приложения. В противном случае, вы чрезмерно инженер.

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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