Encapsular casos de uso em um software

Question

Normalmente escrevo casos de uso para todo o software que desenvolvo. Para cada caso de uso, geralmente escrevo um controlador que direciona o fluxo (implementa um caso de uso).

Recentemente, comecei a desenvolver aplicativos da Web usando o ASP.NET MVC. Uma das melhores práticas do ASP.NET MVC é manter muito menos lógica nos controladores. Não consigo descobrir como vou mudar meu design para refletir isso.

Eu basicamente quero uma maneira de encapsular meus casos de uso.

Answer 1

Crie um componente de negócios para encapsular casos de uso. Por exemplo, se você tiver um sistema de gerenciamento de licenças, teria casos de uso como solicitar uma licença, aprovar uma solicitação de licença, rejeitar uma solicitação de licença etc. Para isso, você pode criar um componente de negócios (classe) chamado Leave Manager com métodos (funções /operações) como "aplicar", "aprovar", "rejeitar" etc. Esses métodos encapsularão seus casos de uso. Esses métodos levariam suas entidades comerciais e as classes de armazenamento de dados como entrada e executariam o caso de uso.

class LeaveManager{
     int Apply(from, to);

     bool Approve(leaveApplicationId, approverId);

     bool Reject(leaveApplicationId, approverId);
}

Você pode usar este componente de negócios em seus controladores para executar o caso de uso, fornecendo os parâmetros necessários.

Answer 2

Eu acho que ter um modelo gordo e um controlador magro geralmente é uma boa prática em qualquer idioma e não especificamente .NET MVC. Confira este bom artigo Isso passa por um cenário de amostra mostrando as vantagens de um modo de gordura em Ruby nos trilhos (mas as idéias se aplicam a qualquer idioma).

Para representar os casos de uso em seu código, acho que um lugar muito melhor para eles está em casos de teste e não para o controlador.

Answer 3

Empurre o máximo possível de lógica de negócios para seus modelos e classes auxiliares e use os controladores principalmente para lidar com chamadas de URL e instanciar os modelos relevantes, recuperar dados deles e empurrar dados para as visualizações. Vistas e controladores devem ter o máximo de decisões possível.