« Voltar
em .net core c# asp.net core controller mvc
Seus controllers devem ser leves

Seus controllers devem ser leves.

Provavelmente você já ouviu falar que um controller deve ser leve ou até mesmo magro.

Mas o que isso significa?

O papel de um controller

Vamos dar uma olhada no fluxo padrão de uma aplicação ASP.NET MVC:

  1. O navegador faz uma requisição para o servidor;
  2. O servidor recebe a requisição e direciona para o controller designado e esse controller, por sua vez, chama uma lógica na camada de modelo;
  3. O modelo faz alguma operação, consulta dados no banco, conversa com um WS, etc. E no final avisa o controller que terminou;
  4. O controller chama a camada de visualização;
  5. A aplicação devolve uma resposta para o navegador em um formato que ele entenda, ou seja: html, css e javascript.

Claro que nem sempre a requisição será assim e eu estou omitindo alguns detalhes, mas é só pra gente focar no que é importante aqui :)

Agora, vamos pensar: qual o papel de um controller?

Quando trabalhamos com ASP.NET MVC ou qualquer outro framework baseado no padrão MVC, a função dos controllers basicamente é: receber uma requisição, redirecionar para a lógica necessária (no modelo) e, no final, devolver uma resposta ao usuário.

Um controller não deve ter lógica de negócio e fazer trabalho demais.

Code smell

Se você olhar pra um controller e o código dele estiver muito grande é possível que ele esteja pesado, fazendo trabalho demais.

Lembre-se, o papel do controller é rotear requisições para uma lógica de negócio e depois devolver uma resposta para o cliente.

Temos que tomar muito cuidado com qualquer coisa além disso.

Um exemplo

Vamos supor que temos um e-commerce e que a url /produto/lista busca uma lista de produtos no banco de dados e mostra eles em uma tela.

E temos o seguinte controller pra atender essa requisição:

public IActionResult Lista()  
{
    using(AppDbContext contexto = new AppDbContext())
    {
        var produtos = contexto.Produtos.ToList();
        return View(produtos);
    }
}

Bem, esse código não está muito longo, certo?
Aqui, estamos:
1. Abrindo uma conexão com o banco de dados através do DbContext;
2. Buscando a lista de produtos e jogando em uma variável;
3. Chamando a camada de visualização passando a lista como parâmetro.

Não parece tão ruim.

Mas, pense comigo: é papel do controller gerenciar conexão com banco de dados?
E se eu tivesse que listar produtos em uma outra parte da minha aplicão, reescreveria esse código pra listar?

Temos aí um Code Smell.

Isolando o código

Esse código que acessa o banco na verdade deve ficar em uma outra classe, uma classe de acesso a dados. Um tipo de classe que chamamos de Data Access Object, ou DAO.

public class ProdutoDAO  
{
     public IList<Post> Lista()
     {
          using(AppDbContext contexto = new AppDbContext())
          {
              return contexto.Produtos.ToList();
          }
     }
}

E aí, no controller, invocamos essa lógica:

public IActionResult Lista()  
{
    var produtos = new ProdutosDAO.Lista();
    return View(produtos);
}

Sempre que precisar de uma lista de produtos em qualquer lugar da aplicação, agora é só chamar esse método.

Conclusão

Eu usei um exemplo simples pra dizer que: não colocamos regra de negócio nos controllers.

Cedo ou tarde você vai ter problemas ou vai ter que reescrever código pra fazer coisas redundantes :)


Quer ficar em dia com os meus posts e novidades?

Participe do grupo no Telegram!

Aproveite e também e inscreva na minha newsletter, me segue no Twitter e na minha página!

Se você gosta dos meus posts, me apoie pra eu m

comments powered by Disqus