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

StackOverflow https://stackoverflow.com/questions/235233

Вопрос

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

До сих пор все демонстрации 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 & amp; Практика . И я верю в пословицу «Картинка стоит тысячи слов».

Диаграмма показывает архитектуру слоев MVC и бизнес-сервисов

Это захватывающий вопрос.

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top