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

Question

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

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

Answer 1

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

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

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

Answer 2

Похоже, что вы после чего-то вроде шаблона репозитория. Вы можете прочитать об этом здесь:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

Этот ответ здесь может также помочь:

Best Repository Pattern for ASP.NET MVC

Answer 3

Посмотрите на article из MSDN лучших практик.

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

Answer 4

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

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

    public MyService(IFirstDependency firstService, ISecondDependency secondService) 
    { 
    } 

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

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

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

Answer 5

Цитируя “Business logic should be in a service, not in a model”?:

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

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