ASP.NET MVC - Бизнес-логика должна существовать в контроллерах?
2 ответа
Бизнес-логика должна действительно быть в модели. Необходимо стремиться к толстым моделям, тощим контроллерам.
, Например, вместо наличия:
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 в смысле действительно размещения "бизнес-логики" полностью в модели. Martin Fowler указал, что MVC не является шаблоном в смысле Банды Четыре. Скорее это - парадигма, что программист должен добавить шаблоны к , если они создают что-то вне игрушечного приложения.
Так, короткий ответ - то, что "бизнес-логика" не должна действительно жить в контроллере, так как контроллер имеет добавленную функцию контакта с представлением и взаимодействием с пользователем, и мы хотим создать объекты только с одной целью.
А более длинный ответ - то, что необходимо поместить некоторую мысль в дизайн образцового слоя прежде просто движущаяся логика от контроллера до модели. Возможно, можно обработать всю логику приложения использование REST, в этом случае дизайн модели должен быть довольно четким. В противном случае необходимо знать то, что приближается, Вы собираетесь использовать, чтобы помешать Вашей модели становиться чрезмерно увеличенной в размере.