O Padrão MVC

    O MVC, diferente do que muitos pensam, não é um design pattern, mas um architectural pattern, já que ele demonstra como utilizar os recursos de forma eficaz ao invés de demonstrar como escrever um código eficazmente. MVC é um acrônimo para Model-View-Controller, onde o Model é uma camada responsável pelas regras de negócio do software, a View uma camada responsável pela User-Interface e o Controller ocupa a função de desenrolar um processo do programa interligando as demais camadas.

Figura 01 – Demonstração de uma arquitetura MVC

    O caminho do processo indicado no diagrama não é necessáriamente fixo. É possível encontrar outros padrões ditos como MVC que o caminho se modifica quase que por completo. Ou seja, não necessáriamente teremos o usuário interagindo com o programa que resultará em uma execução na camada de Controller, que manipulará o Model, que como resultado manipulará a View a ser no final entregue ao usuário. Poderíamos ter um MVC onde o usuário interage com o programa, que resulta em uma execução no Controller que solicitará a exibição de uma View, que por sua vez se comunicará com a camada Model a fim de capturar dados. Veja esse exemplo no diagrama abaixo.

Figura 02 – Demonstração de uma segunda arquitetura MVC

    Mas não seria possível que todos esses padrões resultados de modificações pudessem ser chamadas de MVC se não houvesse algo em comum a todos ou algo que os defina como MVC. Ou seja, eles não são completamente diferentes, eles possuem pontos em comum.

    O primeiro ponto importante a se observar é que sempre deve haver as três camadas, Model, View e Controller.  Essas três camadas podem estar explícitas em nome de pacotes ou em referências no nome das classes, como por exemplo, ProductController ou ProductModel, ou podem estar implícitas no programa, onde há a necessidade de uma avaliação maior das funcionalidade para se descobrir qual camada está presente, mas importando que estejam todas presentes.

    Um segundo ponto a entender é que sempre a interação do usuário com o software irá primeiramente ir para o Controller. O Controller no MVC é o entry-point, ou o ponto de entrada de uma requisição do usuário. Tudo o que o usuário solicitar ao programa terá como ponto inicial o Controller, ou seja, a primeira camada a entrar em contato com a solicitação é o Controller.

    Outro importante ponto que devemos observar é que se o Controller é o entry-point de uma requisição do usuário, a View será o end-point dessa mesma requisição. Ou seja, depois de toda interação entre as camadas do MVC, a View será sempre a última, por ser responsável em exibir o resultado final em uma UI.

    O quarto e último ponto a ser observado é que todas as camadas podem entrar em contato uma com as outras. Não importa a combinação que seja feita, todas as camadas podem se interagir.

    Tudo isso nos leva a entender que qualquer arquitetura pode ser MVC, desde que possua as 3 camadas, Model responsável pelas regras de negócio, View responsável pela User-Interface e o Controller a camada responsável por conduzir o processo entre as camadas, sendo o Controller a camada entry-point, a View a camada end-point, e desde que não haja limitação para interação entre as camadas.