oi car ada uma olhada neste post bem explicativo e depois me fala o que vc achou
Sim, assunto batido! Model View Controller! Mas é muito comum encontrarmos pela internet tutoriais um pouco estranhos, visões às vezes que parecem particulares, diagramas errados e alguns
ainda com dúvidas.
O conceito do MVC é extremamente simples mas a sua visualização não é lá tão trivial assim. O artigo tem 2 objetivos principais: Relembrar a teoria e mostrar uma visualização simplificada do conceito.
Então vamos lá!
Entendendo o papel do M – Model
Pessoal, a idéia é simples: Quando pensamos em regras de negócio, estamos pensando no Modelo da aplicação. Basicamente é isto. No Model podemos ter validações, acesso a banco, acesso à arquivos, cálculos, etc.
O usuário, por exemplo, coloca um produto em um carrinho de compras e é no Model que faremos o cálculo final do pedido(descontos, juros), que validaremos a conta do usuário, que calcularemos o frete, que validaremos o endereço e por aí vai.
Mas como o usuário seleciona um produto em um carrinho de compras por exemplo? Como insere um Endereço para a entrega? Na View!
Entendendo o papel do V – View
A View só existe por um único motivo: Mostrar dados! Na prática isso <del style="margin:0px;padding:0px;font-size:14px;">nunca</del> muitas vezes não acontece, mas deveria! Você que já desenvolveu em Delphi/VB com toda certeza já viu regras
em um botão. Você que já desenvolveu em Java também já viu centenas de regras nas páginas JSP ou espalhadas em Servlets que criam as páginas. Isso é feio! O dia que precisarmos mudar de JSP para JSF ou GWT simplesmente não mudaremos!
Mas e agora? Entendido o conceito básico do Model, como a View passa os valores digitados/selecionados para o Model? Passa direto? Não!
Entendendo o papel do C – Controller
Aqui temos um maestro! Temos regras de negócio no Controller? Não! Temos visualização no Controller? Não! O Controller simplesmente delega para o Model as solicitações da View. O Controller é burro no sentido de regras de negócio da aplicação. Ele é responsável
por saber quem está pedindo algo e a quem enviará este algo!
O Controller conhece a View e conhece o Model mas o Model não conhece a View, porém a View observa o Model e este avisa quando seus dados foram atualizados, para a View mostrá-los.
Ok! Depois dessa frase bagunçada, nada como um pequeno esquema para entendermos melhor:
Veja como é simples com o diagrama acima:
O Controller conhece a View e conhece o Model. Isto porque ele recebe as requisições do usuário da View e envia para o Model fazer algo com estas requisições. Exemplo: O usuário quer saber o endereço
de uma residência a partir de um cep digitado.
O Model simplesmente recebe a requisição, faz toda a mágica (persiste dados, valida informações, etc) e fica com os dados prontos (atualizados) para serem visualizados novamente pela View.
A View fica observando o Model e quando este é atualizado, a View mostra os dados atualizados para o usuário.
E o Model acaba não conhecendo ninguém!
Legal! E por que eu trabalharia desta forma?
Porque, além de elegante, é profissional! Mas se você não se convenceu com estes argumentos, podemos ter outro: é Seguro! Temos aqui uma separação bem clara entre a Visualização e as Regras de Negócio.
Caso você queira modificar uma regra, como um cálculo de juros, você precisaria apenas modificar o seu Model (e espero que em um só local! =) ) e não precisaria se preocupar com a visualização.
O mesmo vale para a View. Caso você queira modificar uma tela inteira, não precisaria se preocupar com as regras e sim somente com a tela.
Um outro motivo muito forte é que você pode querer disponibilizar os seus métodos em um WebService por exemplo e com uma separação clara do seu modelo, isso seria facilitado, e muito!
Imagine que você tenha uma aplicação Web e outra Desktop (JSF e Swing por exemplo) mas que façam a mesma coisa. Seria muito ruim ter funcionalidades iguais nos dois ambientes pois teríamos que manter as duas iguais. Uma forma seria disponibilizar as funcionalidades
em um ponto único e acessá-las nas duas aplicações. Com uma separação clara do modelo poderíamos disponibilizar estas funcionalidades por um WebService, Rest, EJB, etc.
Finalizando
O MVC é um padrão de arquitetura que existe, a grosso modo, para facilitar a manutenção da nossa aplicação, facilitar a adição de funcionalidades e facilitar a testabilidade da aplicação.
Se você ainda escreve regras de negócio nas suas páginas/forms, tente desenvolver com este padrão e veja a diferença na manutenção e na adição de funcionalidades.
No próximo post veremos um exemplo simples de implementação de uma funcionalidade utilizando o padrão MVC e veremos como é simples melhorarmos a nossa aplicação deixando-a profissional.
É isso pessoal! Abraços!
