Должен быть Уровень служб в Asp.net mvc?
Должен быть Уровень служб в Asp.net MVC между Контроллером и Репозиторием? Поскольку Репозиторий там только для Доступа к данным. Некоторая бизнес-логика пропущена в Контроллер. Это могло бы создать проблему, если та же операция используется классическим Asp. Сетевой клиент, поскольку мы должны копировать логику в Контроллере.
6 ответов
Я настоятельно рекомендую использовать уровень обслуживания, чтобы вы могли поделиться общие функции между различными веб-приложениями. Возможно, архитектура уже существует, и вы можете добавить новый веб-сайт mvc в интерфейсную часть.
Для простых архитектур, построенных с нуля, это может оказаться излишним.
Если вы будете следовать Domain Driven Design до буквы, вы обнаружите, что существует 3 типа сервисов (разве вы не любите перегруженные термины?).
- Domain Services : инкапсулирует бизнес-логику, которая естественным образом не вписывается в объект домена, и НЕ является типичными операциями CRUD - они относятся к Repository.
- Службы приложений : Используются внешними потребителями для взаимодействия с вашей системой (вспомните Веб-службы). Если потребителям нужен доступ к операциям CRUD, они будут представлены здесь (но обрабатываются соответствующим Repository)
- Infrastructure Services : Используются для абстрагирования технических проблем (например, MSMQ, почтовый провайдер и т.д.)
Похоже, вам нужны Domain Services для инкапсуляции/обмена бизнес-логикой.
Надеюсь, это поможет!
Мне нравится дополнительный уровень абстракции, который сервисный уровень обеспечивает между моими контроллерами и хранилищами. Я чувствую, что это очень помогает в реализации принципа единой ответственности".
ТБХ, я пошел в обе стороны. Моя текущая точка зрения такова, что репозиторий - это служба, это просто служба, которая выполняет работу по обработке операций CRUD для совокупного корня домена. теперь, если ваши «репозитории» напрямую сопоставляются 1: 1 с вашими объектами (и, следовательно, не репозиториями в такой степени, как DAO), тогда я мог бы увидеть аргумент. Но обычно я добавляю уровни абстракции по мере необходимости, но только после того, как докажу, что они необходимы для данного приложения. В противном случае вы переусердствуете.
Я немного поэкспериментировал с этим. Приложение, которое я создавал, было довольно CRUD-у, и мой уровень обслуживания в конечном итоге предоставил почти те же интерфейсы, что и мои репозитории. Кроме того, большинство вызовов служб не добавляли никакой дополнительной логики поверх репо, они были просто сквозными методами. Единственное место, где уровень сервиса делал что-либо, было во время обновления или вставки новой записи. Я решил, что в системе на основе CRUD уровень обслуживания вызывает больше трений, чем добавляет ценности . В итоге я расширил классы своей бизнес-модели, чтобы логика обслуживания была представлена как операции с моделью, что позволило сохранить мои методы контроллера компактными и чистыми.
Однако я думаю, что в системе, в большей степени управляемой поведением, уровень сервиса может добавить больше ценности.
В большинстве случаев мне нравится иметь репозитории прямо в контроллере, и я делаю сервис там, где чувствую утечку. Я стараюсь иметь богатые объекты предметной области, но в тех случаях, когда логика не подходит для классов предметной области, я создаю службу.