Подтвердить что ты не робот

Создание уровня сервиса для моего приложения MVC?

Из того, что я понимаю, MVC отделяет определения (модель) класса от представления (представления) через "клей", который является контроллером. Контроллер должен иметь отдельную ответственность и, следовательно, быть поддающимся проверке. ViewModels используются для объединения данных из нескольких объектов и для "массажа" данных с контроллера для представления.

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

4b9b3361

ОТВЕТЫ

Ответ 1

Обычно я использую уровень сервиса при разработке приложения ASP.NET MVC. Он похож на шаблон уровня обслуживания, о котором рассказывает Мартин Фаулер в "Шаблонах архитектуры корпоративных приложений". Он инкапсулирует вашу бизнес-логику и делает контроллеры довольно тонкими. В основном контроллеры используют сервисный уровень для получения моделей домена, которые затем преобразуются в модели просмотра. Я также использую Unit of Work Design Pattern для обработки транзакций и Репозиторий Шаблон, чтобы инкапсулировать уровень доступа к данным для более легкого модульного тестирования и возможности легко менять ORM. На этом рисунке показаны типичные слои, которые я использую в приложении MVC.

MVC Architecture

Сервисный уровень помечен как "Уровень приложения или домена" на этой диаграмме, потому что я нахожу, что люди путаются, когда вы используете термин "Уровень обслуживания". Они склонны думать, что это веб-сервис. Это на самом деле сборка, которая может использоваться вашей любимой технологией веб-сервисов, такой как ASP.NET Web API или WCF, а также контроллер.

Что касается соглашений об именах, я обычно использую то, что описывает домен, за которым следует служба. Например, если у меня есть уровень обслуживания, который обрабатывает членство пользователя, тогда у меня будет класс под названием MembershipService, который имеет все методы, необходимые контроллерам и веб-службам для запроса и управления доменом членства. Обратите внимание, что у вас может быть несколько доменов в одном приложении, поэтому вы можете иметь несколько уровней обслуживания. Моя точка зрения заключается в том, что вам не нужно иметь один монолитный сервис, который будет обслуживать все приложение.

Ответ 2

Мой совет - создать отдельные классы, называемые "сервисы". Поместите их в проект библиотеки классов (или пространства имен) и сделайте их независимыми в инфраструктуре инфраструктуры MVC. Я рекомендую использовать также некоторую инъекцию зависимости (лучше всего - инъекция конструктора). Тогда ваши классы обслуживания могут выглядеть так:

 public class MyService : IMyService
 {
     IFirstDependency _firstService;
     ISecondDependency _secondService;

     public MyService(IFirstDependency firstService, ISecondDependency secondService)
     {
     }

     public Result DoStuf(InputDTO)
     {
         // some important logic         
     }
 }

Затем вы используете эти службы у своих контроллеров. Посмотрите здесь для полного примера.

В соответствии с репозиториями - мой совет заключается в том, чтобы не использовать их, если вы собираетесь использовать некоторые современные ORM (NHibernate, EntityFramework), поскольку ваша бизнес-логика будет инкапсулирована на уровне обслуживания, и ваша база данных будет уже инкапсулирована ORM рамки.

Ответ 3

Взгляните на статью из лучших практик MSDN.

Исходный код приложения в статье можно найти здесь.

Ответ 4

Цитата из "Бизнес-логика должна быть в сервисе, а не в модели" ?:

В архитектуре MVP/MVC/MVVM/MV * службы вообще не существуют. Или, если это так, этот термин используется для обозначения любого общего объекта, который может быть введен в контроллер или модель представления. Бизнес-логика в вашей модели. Если вы хотите создать "объекты обслуживания" для организации сложных операций, которые рассматриваются как детализация реализации. К сожалению, многие люди реализуют MVC, но это считается анти-шаблоном (Anemic Domain Model), потому что сама модель ничего не делает, это всего лишь куча свойств для пользовательского интерфейса.

Некоторые люди ошибочно полагают, что использование метода 100-строчного контроллера и превращение его в услугу каким-то образом создает лучшую архитектуру. Это действительно не так; все, что он делает, это добавить другой, возможно, ненужный слой косвенности. Практически говоря, контроллер все еще выполняет свою работу, он просто делает это через плохо названный "вспомогательный" объект. Я настоятельно рекомендую представить демонстрационную версию Jimmy Bogard Wicked Domain Model для ясного примера того, как превратить модель анемической области в полезную. Это требует тщательного изучения моделей, которые вы публикуете, и какие операции действительно действительны в бизнес-контексте.