MVC: o mito

Um assunto tão polêmico quanto mamilos.

Antes de explicar o que é o MVC e qual a sua importância no desenvolvimento, vamos entender os problemas que nos levam a sua utilização.

Como estão seus códigos? Seu arquivo de visualização mexe diretamente com o banco? Existem regras de negócio espalhadas? Poucos arquivos que fazem muita coisa? Então estamos com uma série de problemas.

Digamos que você esteja trabalhando com outras pessoas em um projeto, e que o contexto acima faça sentido nesse projeto. Ao longo do desenvolvimento, os integrantes da equipe vão sendo trocados, imaginem o trabalho que um novo dev vai ter para entender as regras de negócio nesses sistema, ou o impacto que uma mudança em uma função/método pode causar, já que a rastreabilidade é muito ruim. E é aí que entra o MVC.

Conhecendo o MVC

MVC nada mais é que um padrão arquitetural. Mas então o que seria um padrão arquitetural? Um padrão arquitetural expressa um esquema de organização estrutural fundamental para sistemas de software. No MVC, temos uma arquitetura de 3 camadas. Resumindo, nós dividimos as responsabilidades do nosso sistema, lógica em uma parte, visualização em outra. A arquitetura MVC divide nosso sistema em 3, são elas:

M(odel) ~> é a camada que lida com os dados, regras de negócio, é nela por exemplo que os dados deste artigo, sejam os comentários, conteúdo do artigo, etc, são buscados do banco. É nessa camada que o sistema trabalharia com a permissão de usuários, entre outras coisas lógicas.

V(iew) ~> é onde o usuário interage, é o que ele vê. Exemplo: a leitura deste artigo, o que você está vendo nada mais é do que a camada de visualização, um formulário, uma listagem, etc.

C(ontroller) ~> é a camada de controle da sua aplicação, quando você acessou a url deste artigo, foi a camada de controle que soube manipular um model para buscar os dados e jogar esses dados em uma view.

Continuando…

Sabemos agora como funciona a arquitetura MVC, sabemos que aquele “nosso sistema” precisa ser refatorado, precisa ser melhorado.

Mas a vida é uma caixinha de surpresas…

Continuando com o exemplo do sistema, digamos que ele esteja absurdamente grande, temos um model com muita responsabilidade, está começando a ficar complicado dar manuutenção nesse sistema, dividir o projeto em apenas 3 camadas já não parece ter um resultado tão agradável quanto esperamos .

Você deve estar se perguntando: “Entendi a arquitetura MVC mas parece que ela não resolve meu problema, e agora?” Calma pequeno littlefoot, entenda o seguinte: o MVC no seu “estado natural”, utilizando somente 3 camadas, já resolve uma série de problemas, mas em sistemas muito complexos, e principalmente com as técnologias atuais, essa arquitetura já se apresenta defeituosa, mas...

…Mas somos como Joseph Climber, e não desistimos nunca

Para suprirmos as nossas necessidades, surgiram novas camadas, e isso é bom, pois conseguimos dividir as responsabilidades em nossa aplicação, conseguimos resolver problemas que o MVC não resolvia, veremos a seguir algumas camadas extras que surgiram:

Middleware ~> é uma camada que fica antes da chamada aos controllers, como assim? Ela é muito poderosa em vários casos, vamos a um exemplo: imagine que um usuário está tentando acessar determinado recurso da aplicação, antes, você teria que verificar se o usuário está autorizado a acessar este recurso em cada controller, sendo muito trabalhoso, mas hoje, essa responsabilidade fica no middleware, ele será executando antes mesmo de chegar nos nossos controllers.

Services ~> é camada onde estariam suas regras de negócio, é ela que seu controller irá chamar para executar a lógica do sistema. Mas tenha cuidado, uma coisa que ela não faz, é a interação com o banco de dados diretamente.

Repository ~> é a camada que fará a manipulação de dados, seja no banco ou em memória, ela fará o trabalho de por exemplo: inserir, listar, deletar, atualizar os dados.

Model ~> já foi falada anteriormente, porém, agora ela não terá mais regras de negócio, e sim, guardará entidades, as entidade nada mais são do representações de tabelas do seu banco.

Mas a vida…

Vimos aqui a estrutura do MVC e sua evolução, mas sempre espere por novas evoluções dessa arquitetura, as técnologias irão sempre se atulizar, o que irá gerar novos problemas e novas soluções para esses problemas. Mas independente de nome ou quantidade de camadas o importante é saber utiliza-las, saber organizar o código, faze-lo legível.

Caso eu tenha cometido algum equívoco, não deixem de me corrigir.