ASP.NET MVC - должна ли бизнес-логика существовать в контроллерах?

Пару дней назад Дерик Уитакер опубликовал статью, в которой затронул вопрос, который меня уже давно интересовал: должна ли бизнес-логика существовать в контроллерах?

До сих пор все демонстрации ASP.NET MVC, которые я видел, предоставляют доступ к репозиторию и бизнес-логику в контроллере. Некоторые даже добавляют туда валидацию. В результате получаются довольно большие и раздутые контроллеры. Действительно ли это способ использования инфраструктуры MVC? Похоже, это закончится большим количеством дублированного кода и логики, распределенной по разным контроллерам.

Бизнес-логика действительно должна быть в модели. Вы должны стремиться к толстым моделям, худым контроллерам.

Например, вместо:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Я бы предпочел:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Это предполагает, что налог рассчитывается внешней службой, и требует, чтобы ваша модель знала об интерфейсах с вашими внешними службами.

Это сделает ваш контроллер примерно таким:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Или что-то вроде того.

Мне нравится диаграмма, представленная Microsoft Patterns & Practices . И я верю в пословицу: «Картинка стоит тысячи слов».

Это интересный вопрос.

Я думаю, это интересно, что большое количество примеров приложений MVC на самом деле не соответствует парадигме MVC в том смысле, что полностью помещает «бизнес-логику» в модель. Мартин Фаулер указал, что MVC не является шаблоном в смысле «Банды четырех». Скорее всего , это парадигма , что программист должен добавить шаблоны для , если они создают нечто большее , чем игрушка приложения.

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

Более длинный ответ заключается в том, что вам нужно немного подумать над дизайном уровня вашей модели, прежде чем просто перемещать логику от контроллера к модели. Возможно, вы сможете обрабатывать всю логику приложения с помощью REST, и в этом случае дизайн модели должен быть достаточно ясным. Если нет, вы должны знать, какой подход вы собираетесь использовать, чтобы ваша модель не раздувалась.

Вы можете проверить это замечательное руководство Стивена Вальтера, в котором показана проверка с помощью уровня обслуживания .

Узнайте, как переместить логику проверки из действий контроллера в отдельный уровень сервиса. В этом руководстве Стивен Вальтер объясняет, как можно обеспечить четкое разделение проблем, изолировав уровень сервиса от уровня контроллера.

Бизнес-логика не должна содержаться в контроллерах. Контроллеры должны быть максимально тонкими, в идеале следовать скороговорке:

1. Найти объект домена
2. Действовать на объект домена
3. Подготовить данные для просмотра / возврата результатов

Дополнительно контроллеры могут содержать некоторую логику приложения.

Так где же мне разместить свою бизнес-логику? В модели.

Что такое модель? Это хороший вопрос. См. Статью Microsoft Patterns and Practices (слава AlejandroR за отличный поиск). Здесь есть три категории моделей:

• Модель представления : это просто пакет данных с минимальной логикой, если таковая имеется, для передачи данных из представлений и в представления, содержит базовую проверку полей.
• Модель предметной области : жирная модель с бизнес-логикой, работает с одним или несколькими объектами данных (то есть с объектом A в данном состоянии, а не с объектом B).
• Модель данных : модель с учетом хранения, логика, содержащаяся в одном объекте, относится только к этому объекту (т.е. если поле a, то поле b)

Конечно, MVC - это парадигма, которая бывает разных видов. Здесь я описываю MVC, занимающий только верхний уровень, см. Эту статью в Википедии.

Сегодня MVC и аналогичные модели-представления-презентаторы (MVP) представляют собой шаблоны проектирования «Разделение проблем», которые применяются исключительно к уровню представления более крупной системы. В простых сценариях MVC может представлять первичный дизайн системы, обращаясь непосредственно к базе данных; однако в большинстве сценариев Контроллер и Модель в MVC слабо зависят от уровня / уровня службы или данных. Это все об архитектуре клиент-сервер

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