MVC - É pra comer?

Model-View-Controler, ou MVC para os mais íntimos, isso não é uma linguagem, não é um framework, tão pouco uma IDE, mas então o que pode ser?

MVC é um padrão de desenvolvimento para projetos, principalmente, de grande porte cuja manutenção/mudança é constante, trabalhando com este padrão de desenvolvimento que separa o projeto em três partes, a manutenção e até o desenvolvimento ficam mais fáceis. 

Como funciona?

Model – Camada de negócios.
View – Camada de visualização.
Controller – Camada de controle e validações.

Nota: Apesar de muitas biografias dizerem que não existe “camadas” na MVC, estas também não informam o que realmente é esta separação, porém a separação destas partes do projeto são, a grosso modo, realmente separadas em camadas, que é a definição utilizada aqui. 

Durante a programação do projeto, deve-se separar todas as classes, jsps, imagens, xmls e demais arquivos em algumas camadas, em se tratando de Java, podemos trabalhar com pacotes. 

MODEL, tudo aquilo que se refere à regras de negócio deve ser guardado no(s) pacote(s) da camada model.
VIEW, tudo que for relativo à tela, o que o usuário pode enxergar pertence à camada view e deve ser colocado no(s) pacote(s) referente à view, no caso dos jsps e imagens não á necessidade pois é subentendido que mesmo não estando em pacotes, todos os arquivos jsp, HTML, javascript, css, etç pertencem a esta camada.
CONTROLLER, aqui é onde a porca torce o rabo, ou melhor, onde a discussão se inicia, uma das práticas da MVC diz que esta camada serve para fazer a comunicação entre a VIEW e a MODEL, porém uma outra prática da MVC informa que esta camada serve apenas para efetuar as validações da camada VIEW.

 A partir deste ponto, irei falar sobre duas formas diferentes de MVC, pois hoje em dia existe uma vasta discussão que nunca chega ao fim sobre a “verdadeira” forma da MVC. Por tanto irei comentar sobre as duas variações desta arquitetura, para você poder ter uma noção de como funciona e procurar realmente o que quer pra você.

Primeiro, irei apontar a camada controller como uma comunicação entre as outras duas camadas, segue imagem.

Neste caso, é possível notar que a camada view não enxerga de forma alguma a camada model.

Vejamos no exemplo:
Em um cadastro on-line, possuímos as páginas e imagens que o cliente pode ver e tocar com o mouse (view), temos as validações (controller) e após isso temos as regras de negócio e gravação em banco de dados (model).
Neste mesmo exemplo, o cliente preenche todos os dados na tela e clica em no botão de envio do formulário, neste momento todos os dados são repassados para a camada controller, as classes desta camada fazem a verificação dos dados informados, verificam se estão corretos, fazem a validação do CPF, etç. Se algo estiver errado o controller retorna uma mensagem de erro para a camada view, que a exibe na tela, se estiver tudo correto a camada controller repassa estas informações para a camada model.
A camada model, recebe as informações e verifica se o cliente é menor de idade (regra de negócio), em caso positivo estas informações são armazenadas na tabela X, caso negativo (cliente maior de idade) as informações são armazenadas na tabela Y.

Existe também a definição que inutiliza a camada Controller, informando que esta só serve para realizar validações, é um suporte da camada view.

No mesmo exemplo do cadastro citado acima, quando o cliente clica no botão de envio do formulário, este é repassado à camada controller que efetua as validações e repassa para a camada model, até aqui está igual a definição anterior, porém, em uma tela que não existe validação de formulário, por exemplo “escolha as opções A ou B”, como não há validação neste caso (validação de campo nulo pode ser realizada direto no jsp/html) ao ser acionado o botão de ação, a camada view repassa as informações diretamente para a camada model.

Nesta definição possuímos duas estradas virtuais, na imagem representada pela seta vermelha (ida e volta passando pelo controller) e pela seta verde (ida e volta sem passar pelo controller).

Mas como fazer as separações?

Se fosse fácil não teria graça…As camadas têm que ser muito bem planejadas, e deve ser impressa a seguinte frase “Não importar classes e métodos do pacote xx.xxx.xxx pelo pacote xx.xxx.xxx”, esta frase deve ser colada na mesa de cada desenvolvedor…

Como MVC é um padrão de desenvolvimento, não existe uma barreira que impeça você de, por exemplo, fazer a validação do CPF na camada de modelo, ou efetuar uma gravação em banco de dados na camada de visualização, porém se a MVC for seguida muito tempo e sangue serão economizados e casamentos poderão ser mantidos (viradas de noite prestando manutenção em código pode causar divórcio).

Algumas práticas em Java podem ser utilizadas para ajudar a manter o padrão de desenvolvimento, por exemplo a utilização de Implements e classes Abstratas, que bloqueiam a utilização em determinadas ocasiões, os modificadores de acesso Private, Public e Protected devem ser utilizados com sabedoria também, para restringir e/ou permitir acesso as classes e métodos corretos.

Agora, com a faca e o queijo na mão, boa sorte na implementação da MVC