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

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

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

Ответы

Ответ 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);
    }
}

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

Ответ 2

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

Diagram shows architecture of MVC and business sevices layers

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

  • Найти объект домена
  • Закон о домене
  • Подготовить данные для просмотра/возврата результатов

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

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

Что такое модель? Теперь это хороший вопрос. См. статью о шаблонах и практиках Microsoft (для АлехандроР отличная находка). Здесь есть три категории моделей:

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

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

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

Ответ 6

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