O conceito e as dúvidas sobre o MVC

Feliz ano novo, leitores! O primeiro artigo de 2013 traz uma dúvida comum entre os programadores a respeito do MVC, que na verdade acaba se tornando uma má compreensão. Neste artigo pretendo esclarecer alguns fatos sobre o MVC e ressaltar o seu principal objetivo dentro do desenvolvimento de um sotfware. Vamos nessa?

MVC? O que é isso?

Bom, pra começar, MVC é o acrônimo de Model-View-Controller (em português, Modelo-Visão-Controle) e que, como o próprio nome supõe, separa as camadas de uma aplicação em diferentes níveis. Ao contrário do que muitos desenvolvedores dizem, o MVC não é um Padrão de Projeto, mas sim um Padrão de Arquitetura de Software. Essa é uma das dúvidas que mencionei no enunciado do artigo. Na época da universidade, ouvia muitos alunos comentarem que o “projeto do TCC foi desenvolvido utilizando o Design Pattern MVC”, sem notarem que estavam errados. Apesar do MVC introduzir uma forma de desenvolvimento, ele não pode ser considerado um padrão de projeto, uma vez que este é especialmente relacionado com a arquitetura do software. Lembre-se de que existem 23 padrões de projeto (Design Patterns) e o MVC não está entre eles.

Pois bem, embora existam outros padrões de arquitetura de software – como Pipeline, Blackboard, Microkernel e Reflection – o MVC é um dos mais difundidos e utilizados pelos desenvolvedores principalmente pela funcionalidade e objetividade. O MVC define a divisão de uma aplicação em três componentes: Modelo, Visão e Controle. Cada um destes componentes tem uma função específica e estão conectados entre si. O objetivo é separar a arquitetura do software para facilitar a compreensão e a manutenção.

A camada de Visão é relacionada ao visual da aplicação, ou seja, as telas que serão exibidas para o usuário. Nessa camada apenas os recursos visuais devem ser implementados, como janelas, botões e mensagens. Já a camada de Controle atua como intermediária entre as regras de negócio (camada Modelo) e a Visão, realizando o processamento de dados informados pelo usuário e repassando-os para as outras camadas. E por fim, temos a camada de Modelo, que consiste na essência das regras de negócio, envolvendo as classes do sistema e o acesso aos dados. Observe que cada camada tem uma tarefa distinta dentro do software.

Certo, mas qual é a vantagem?

A princípio, pode-se dizer que o sistema fica mais organizado quando está estruturado com MVC. Um novo desenvolvedor que começar a trabalhar no projeto não terá grandes dificuldades em compreender a estrutura do código. Além disso, as exceções são mais fáceis de serem identificadas e tratadas. Ao invés de revirar o código atrás do erro, o MVC pode indicar em qual camada o erro ocorre.

Outro ponto importante do MVC é a segurança da transição de dados. Através da camada de Controle, é possível evitar que qualquer dado inconsistente chegue à camada de Modelo para persistir no banco de dados. Imagine a camada de Controle como uma espécie de Firewall: o usuário entra com os dados e a camada de Controle se responsabiliza por bloquear os dados que venham a causar inconsistências no banco de dados. Portanto, é correto afirmar que essa camada é muito importante.

Posso ter apenas três camadas no MVC?

Eis que essa é outra dúvida bastante questionada pelos desenvolvedores. Embora o MVC sugira a organização do sistema em três camadas, nada impede que você “estenda” essas camadas para expandir a dimensão do projeto. Por exemplo, vamos supor que um determinado projeto tenha um módulo web para consulta de dados. Aonde esse módulo se encaixaria dentro das três camadas?

Bem, este módulo poderia ser agrupado com os outros objetos da camada Visão, mas seria bem mais conveniente criar uma camada exclusiva (como “Web”) estendida da camada de Visão e agrupar todos os itens relacionados a esse módulo dentro dela. O mesmo funcionaria para um módulo Mobile ou WebService. Neste caso, a nível de abstração, essas novas camadas estariam dentro da camada de Visão, mas são unidades estendidas.

Quando desenvolvi o meu projeto na faculdade, também me deparei com a necessidade de uma camada adicional: a camada de acesso ao banco de dados.

Mas o acesso ao banco de dados não é uma função da camada de Modelo?

Sim, é. Inclusive muitos profissionais preferem denominar a classe de Modelo como Business Object Model, responsável pela modelagem e acesso ao banco de dados ao mesmo tempo. Mas essa é uma premissa particular de cada desenvolvedor.

No meu caso, achei conveniente manter as classes do projeto (modelagem) e o acesso ao banco de dados em camadas diferentes. Sendo assim, criei uma camada estendida da camada de Modelo para o acesso ao banco de dados, conhecida como DAO (Data Access Object) ou DAL (Data Access Layer). É uma camada bem simples, apenas com os objetos de conexão com o banco de dados e as instruções SQL, mas que proporcionou uma melhor organização no meu código.

Mas lembre-se: um projeto com várias camadas torna-se tão confuso quanto um projeto de uma camada só. Separe a implementação quando notar que a mesma camada está realizando duas ou mais tarefas diferentes, e que dividindo-as tornará o projeto mais compreensível.

Fico por aqui, pessoal.
Abraço!