ASP.NET 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);
    }
}

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

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

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

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

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

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

Learn how to move your validation logic out of your controller actions and into a separate service layer. In this tutorial, Stephen Walther explains how you can maintain a sharp separation of concerns by isolating your service layer from your controller layer.

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

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

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

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

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

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

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

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

Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system. In simple scenarios MVC may represent the primary design of a system, reaching directly into the database; however, in most scenarios the Controller and Model in MVC have a loose dependency on either a Service or Data layer/tier. This is all about Client-Server architecture

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