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

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

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

Источник

6 ответов

Решение

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

Например, вместо того, чтобы:

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 в смысле истинного помещения "бизнес-логики" в модель целиком. Мартин Фаулер отметил, что MVC не является образцом в смысле "Банды четырех". Скорее, это парадигма, к которой программист должен добавлять шаблоны, если они создают что-то помимо игрушечного приложения.

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

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

Источник

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

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

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

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

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

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

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

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

Источник

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

Источник
Другие вопросы по тегам