ASP.NET MVC - A lógica de negócios deve existir nos controladores?

Derik Whitaker postou um artigo alguns dias atrás que atingiu um ponto que eu estava curioso há algum tempo: a lógica de negócios deve existir nos controladores?

Até agora, todas as demonstrações do ASP.NET MVC que vi colocam o acesso ao repositório e a lógica de negócios no controlador. Alguns até lançam validação lá também. Isso resulta em controladores bastante grandes e inchados. Esta é realmente a maneira de usar o framework MVC? Parece que isso vai acabar com uma grande quantidade de código duplicado e lógica espalhada por diferentes controladores.

A lógica de negócios realmente deve estar no modelo. Você deve buscar modelos gordos, controladores magros.

Por exemplo, em vez de ter:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Eu preferiria ter:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Isso pressupõe que o imposto é calculado por um serviço externo e requer que seu modelo conheça as interfaces de seus serviços externos.

Isso faria com que seu controlador se parecesse com:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Ou algo assim.

Eu gosto do diagrama apresentado por Microsoft Patterns & Practices . E eu acredito no ditado 'Uma imagem vale mais que mil palavras'.

Esta é uma questão fascinante.

Eu acho que é interessante que um grande número de aplicativos MVC de amostra realmente falhe em seguir o paradigma MVC no sentido de realmente colocar a "lógica de negócios" inteiramente no modelo. Martin Fowler apontou que MVC não é um padrão no sentido do Gang Of Four. Pelo contrário, é paradigma de que o programador deve adicionar padrões para se eles estão criando algo além de um aplicativo de brinquedo.

Portanto, a resposta curta é que a "lógica de negócios" realmente não deveria residir no controlador, uma vez que o controlador tem a função adicional de lidar com a visualização e as interações do usuário e queremos criar objetos com apenas um propósito.

Uma resposta mais longa é que você precisa pensar um pouco no design da camada do modelo antes de apenas mover a lógica do controlador para o modelo. Talvez você possa lidar com toda a lógica do aplicativo usando REST, caso em que o design do modelo deve ser bastante claro. Caso contrário, você deve saber qual abordagem usará para evitar que seu modelo fique inchado.

Você pode verificar este tutorial incrível de Stephen Walther que mostra Validando com uma camada de serviço .

Aprenda como mover sua lógica de validação de suas ações do controlador para uma camada de serviço separada. Neste tutorial, Stephen Walther explica como você pode manter uma separação nítida de interesses, isolando sua camada de serviço da camada do controlador.

A lógica de negócios não deve estar contida em controladores. Os controladores devem ser o mais magros possíveis, de preferência, seguir o padrão:

1. Encontrar entidade de domínio
2. Agir na entidade de domínio
3. Prepare os dados para visualizar / retornar resultados

Além disso, os controladores podem conter alguma lógica de aplicação.

Então, onde coloco minha lógica de negócios? No modelo.

O que é modelo? Essa é uma boa pergunta. Consulte o artigo Padrões e Práticas da Microsoft (parabéns a AlejandroR pelo excelente achado). Aqui, existem três categorias de modelos:

• Modelo de visualização : este é simplesmente um saco de dados, com lógica mínima, se houver, para passar dados de e para visualizações, contendo validação de campo básica.
• Modelo de domínio : modelo gordo com lógica de negócios, opera em uma ou várias entidades de dados (ou seja, entidade A em um determinado estado do que ação na entidade B)
• Modelo de dados : modelo com reconhecimento de armazenamento, a lógica contida em uma única entidade se relaciona apenas a essa entidade (ou seja, se o campo a, então, o campo b)

Claro, MVC é um paradigma que vem em diferentes variedades. O que eu descrevo aqui é MVC ocupando apenas a camada superior, vide este artigo na Wikipedia

Hoje, MVC e model-view-presenter (MVP) são padrões de design de Separation of Concerns que se aplicam exclusivamente à camada de apresentação de um sistema maior. Em cenários simples, o MVC pode representar o projeto principal de um sistema, alcançando diretamente o banco de dados; no entanto, na maioria dos cenários, o controlador e o modelo no MVC têm uma dependência flexível em um serviço ou camada / camada de dados. Isso é tudo sobre arquitetura cliente-servidor

Se você usar injetores de dependência, sua lógica de negócios irá para eles e, portanto, você obterá controladores organizados e limpos.