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

Question

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

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

Answer 1

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

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

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);
    }
}

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

Answer 2

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

Answer 3

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

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

Answer 4

Это увлекательный вопрос.

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

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

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

Answer 5

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

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

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

Так, куда я помещу свою бизнес-логику? В модели.

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

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

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

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

Answer 6

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