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

Question

Derik Whitaker apresentou um artigo um par de dias atrás, que atingiu um ponto que eu tenho curiosidade sobre há algum tempo:? deve existir lógica de negócios em controladores

Até agora todos os demos ASP.NET MVC eu vi colocar acesso ao repositório e lógica de negócios no controlador. Alguns até mesmo jogar validação de lá também. Isso resulta em bastante grandes controladores, inchado. Esta é realmente a maneira de usar o framework MVC? Parece que este é apenas vai acabar com um monte de código duplicado e lógica espalhados diferentes controladores.

Answer 1

A lógica de negócios deve ser realmente no modelo. Você deve estar apontando para modelos de gordura, os controladores skinny.

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 é calcular por um serviço externo, e requer o seu modelo de saber sobre as interfaces para seus serviços externos.

Isto faria com que o controlador de olhar algo como:

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

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

Ou algo parecido.

Answer 2

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

Answer 3

Esta é uma pergunta fascinante.

Eu acho que é interessante que um grande número de amostras de aplicações MVC realmente não conseguem 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.

Assim, a resposta curta é que "lógica de negócios" deve realmente não ao vivo no controlador, uma vez que o controlador tem a função adicional de lidar com a vista e usuário interações e queremos criar objetos com apenas um propósito.

A resposta mais longa é que você precisa colocar algum pensamento no design de sua camada de modelo antes apenas movendo a lógica do controlador para o modelo. Talvez você pode lidar com todos os lógica aplicativo usando REST, caso em que o design do modelo deve ser bastante clara. Se não, você deve saber o que se aproximar de você estiver indo para usar para manter o seu modelo de tornar-se inchado.

Answer 4

Você pode verificar este tutorial incrível por Stephen Walther que mostrar Validação com uma camada de serviço .

Saiba como mover a sua validação lógica de suas ações do controlador e em uma camada de serviço separada. No Neste tutorial, Stephen Walther explica como você pode manter um acentuado separação de preocupações isolando sua camada de serviço do seu controlador de camada.

Answer 5

Business Logic não deve estar contido em controladores. Os controladores devem ser tão magro quanto possível, de preferência seguir o padrão de:

1. Encontre entidade de domínio
2. Lei sobre a entidade de domínio
3. Preparar dados para ver os resultados / retorno

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

Então, onde eu coloquei a minha lógica de negócios? Em Modelo.

O que é modelo? Agora que é uma boa pergunta. Por favor, veja Microsoft Patterns e artigo Práticas (parabéns a Alejandror para excelente encontrar). Aqui existem três categorias de modelos:

• Model View :. Isto é simplesmente um saco de dados, com o mínimo, se for o caso, a lógica para transmitir dados de e para pontos de vista, contém validação de campo básica
• Modelo de Domínio : modelo Fat com lógica de negócios, opera em um entidades de dados único ou múltiplo (ou seja, a entidade A em um determinado estado do que a ação na entidade B)
• Data Model : Modelo de Armazenamento-aware, a lógica contida dentro de uma única entidade refere-se apenas a essa entidade (ou seja, se o campo de um campo em seguida, b)

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

Hoje, MVC e modelo-visão-apresentador semelhante (MVP) são a separação de padrões preocupações de design que se aplicam exclusivamente à camada de apresentação de um sistema maior. Em cenários simples MVC pode representar o projeto preliminar de um sistema, atingindo diretamente no banco de dados; no entanto, na maioria dos cenários, o Controlador e Modelo em MVC tem uma dependência solto em um serviço ou dados camada / camadas. Isso tudo é sobre a arquitetura cliente-servidor

Answer 6

Se vc usar dependência Injetores sua lógica de negócio vai para eles e, portanto, você terá controladores arrumado e limpo.