ASP.Net MVC: Muito código nas Controllers
Autor: Eduardo Silva | Publicado: 2012-12-23T15:00:00-08:00

Eu tenho utilizado muito o ASP.Net MVC e sem dúvida é uma grande tecnologia, mas resolvi colocar nesse post alguns problemas que eu passei e como resolvi. 

Com o ASP.Net Web Forms, por padrão, temos um code behind (*.aspx.cs) por página (*.aspx) isso significa que temos tem uma classe, que podemos de certa forma caracterizar como uma controller, responsável por uma View. Já no ASP.Net MVC podemos ter um Controller responsável por varias views. Ex.: ProdutoController&nbsp; responsável pelas view Pesquisar, Detalhe, Edicao. Nesta mesma controller podemos potencializar a sua aplicação deixando-a responsável por responder chamadas de json.
Bom com isso acabamos tendo muito código nas nossas controllers (consultas, escritas, conversões de tipos etc). E isso não é culpa da tecnologia é apenas uma questão de como organizar as idéias e responsabilidades.

Com essa quantidade de código nas Controller fica dificil de dar manutenção, mesmo refatorando em métodos você acaba vendo um código muito extenso na sua controller o que de cara parece ser um mal sinal (ou um mal cheiro). 

Não precisamos "reinventar a roda" para resolver esses problemas, grandes mentes já tem várias sugestões sobre isso e quero apenas apresentar algumas delas que eu estou utilizando e tem me agradado.

CQRS (Command Query Responsibility Segregation) é um padrão que tenho utilizado para organizar esse tipo de coisa, não vou entrar em detalhes sobre o padrão, isso vai ficar para outro post, vou focar apenas em como estou aplicando nos meus projetos.

Consultas

O primeiro problema que eu resolvi foi referente a consultas. Se você utiliza um OR/M como o Entity Framework ou NHibernate com o ASP.Net MVC você pode acabar tendo muito código de consulta dentro da sua controller.

OBS.: Eu não costumo encapsular os frameworks de OR/M com DAOs ou Repositories. Se estiver interessando no motivo leia o artigo abstração da abstração. Só pra reforçar que isso também não é coisa da minha cabeça, Ayende Rahien é um grande defensor da idéia de que abstrair OR/M é um erro.

Eu utilizo para as consultas o Query Object Pattern (link), com isso consigo encapsular as consultas nessas classes. Isso também evita a questão de trazer todas as propriedades das entidades relacionadas na consulta, eu consigo criar consultas espeficidas para fins específicos de uma View, o que traz um grande ganho de performance. (uma coleção de uma determinada entidade para popular um combobox pode te dar muito dor de cabeça. Acredite!).

Escritas

Para as escritas estou utilizando o Command Pattern, com ele eu consigo refatorar o processo de escrita em várias blocos de comando, afinal nem sempre nossas telas só precisamos executar um salvar correto? Como utilizo muito o Entity Framework, também fica fácil seperar esses comandos utilizando uma única instancia de context e controle de transação quando necessário.

Se você pesquisar sobre esse padrão verá outros padrões relacionados como o Tasks e Events, porém os meus projetos até o momento não precisou desse potencial todo.

Basicamente estou organizando os meus projetos da seguinte forma:

Entities
Commands
QueryObjects
Controllers
Views
Models

É claro que isso pode variar de projeto a projeto, mas no geral os projetos que tenho trabalhado esse tipo de organização tem atendido muito bem, sendo bastante produtivo mas sem perder a organização e flexibilidade do código.

Até a próxima!