Que que isso!

Aos que tem dúvidas referentes ao último exercício do Reinaldo, aqui está uma "breve" explicação sobre o assunto. Espero que seja útil. =)

A primeira coisa, é ter certeza de que a lógica do padrão MVC (model-view-controller, ou modelo-visualização-controlador) está clara. Em poucas palavras, é um padrão de projeto que consiste em separar e segmentar tarefas distintas para que fique mais fácil trabalhar no seu sistema.
Em um sistema de vendas por exemplo, você tem uma parte visível (formulários de entrada de dados, edição, listagem,...), uma parte interna ao sistema que mantém os dados das vendas e outra que controla como o usuário do sistema interage com estes dados. De um lado, temos este usuário que só tem acesso a parte visível (afinal, foi feita justamente para ele) e do outro, os dados, em memória ou em um banco de dados por exemplo. Quem define as regras do que pode e o que não, quando, como, etc... é justamente o controlador. Ele é o intermediário entre o usuário e o modelo e faz a ponte entre os dois.

Resumindo:

O Controller despacha as solicitações ao Model; A View "observa" o Model.(wikipedia quote!)

Colocando em uso

Como exemplo do uso e implementação do padrão MVC, vamos usar o último trabalho da aula do Prof. Reinaldo.

A maior parte do código presente neste exercício é, de fato, a implementação do MVC, só que com alguns recursos mais profissionais adicionados. :)

Uma representação gráfica do exercício:

Assim temos:

VIEW

• index.jsp – Página principal, fornece acesso a página de cadastro de novos municípios e para listagem.
• formMunicipio.jsp – Página para inserção de um novo município ou para a alteração de um existente. Note que é a mesma página para ambas as funções.
• mostrarMunicipios.jsp – Página para a listagem dos municípios já cadastrados. Fornece também meios para alterar ou excluir uma entrada.

CONTROLLER

• BusinessLogic.java – Interface. Garante e obriga a todos os controllers implementarem um método específico para funcionarem em nosso sistema.
• MunicipioController.java – Controlador para o modelo Município. Implementa a interface BusinessLogic. Contém (e controla) todas as possíveis operações que podem ser feitas no modelo Município.
• ControllerServlet.java – Servlet de despacho. Ele recebe os dados de qualquer formulário, juntamente com qual controlador ele deve passar o pedido e qual a ação a ser feita. O controlador deve ser passado pelo parâmetro “business” e a ação pelo “action”.

MODELO

• Municipio.java – Modelo/”Bean” que descreve um município. Como visto, deve ter apenas os gets/sets e um conjunto de construtores para serem usados no sistema. É interessante fazer um em branco e um com todos os parâmetros, assim você pode instanciar um objeto em branco para colocar os dados depois ou instanciá-lo já passando os dados imediatamente.

Os outros arquivos, podemos dizer, são auxiliares. Fornecem meios para comunicar com o banco de dados:

• ConnectionFactory.java – Funções para conectar ao banco e fornecer acesso à ele.
• MunicipioDAO.java – Contém todas os métodos de leitura, gravação, exclusão e criação de um município no banco de dados. Eu particularmente não colocaria esta classe como fazendo parte do MODELO no MVC, pois é um intermediário entre o modelo e a camada de persistência.

Até então, as partes separadas estão entendidas, certo? :)
Vamos passar para como elas interagem entre si e o sistema funciona.

Lembram do exercício anterior? Era para apenas gravarmos um município no banco e listar logo em seguida. Bem simples, não precisávamos de excluir ou listar.
Com esta simplicidade, os formulários (páginas JSP) comunicavam direto com o controller apropriado (para municípios), que ficava dentro de “persistirMunicipio.java”.

E se precisássemos das outras funções e, também, de cadastrar UFs, pessoas, etc...? Nosso sistema ficaria cada vez mais complicado e vulnerável a falhas se apenas incluíssemos os JSPs e controllers correspondentes no sistema sem nos preocuparmos com a organização e em estabelecer regras.
Uma idéia seria criarmos uma interface que fizesse a “rota” dos dados para o controller adequado e ao mesmo tempo garantisse o comportamento destes controladores, para não acontecer de fazermos um controller muito diferente do outro e que pudesse causar um problema.

Por isso usaremos o ControllerServlet:

Neste caso, toda e qualquer “remessa” de dados vão para o ControllerServlet. Como havia dito lá em cima, ele faz o despacho dos dados. Mas, despacho para quem, onde, pra quê?

Você diz pra ele. Basta informar qual o controller que cuidará dos dados e qual ação deve ser feita com estes dados.
No gráfico, só temos o MunicipioController ligado ao ControllerServlet. Logicamente, já que nossa aplicação só trabalha com municípios.
Veja também, que a saída do MunicipioController sãos os JSPs novamente, pois, de acordo com a solicitação, somos redirecionados para a página correspondente. E, após o término da solicitação (excluir, alterar, ...) voltamos para as mesmas.
Até aí tudo bem, mas como falo isso para o ControllerServlet?
Estas instruções vão junto com os dados provenientes do formulário. Por exemplo: quando você clica em “Gravar” ao inserir um novo município, juntamente do nome e uf, os comandos dizendo “Estou trabalhando com o modelo Município e quero que seja seja inserido um novo registro” vão junto na requisição. Não acreditam? Olhe no formMunicipio.jsp.

<form name="formMunicipio" action="ControllerServlet">
<input type="hidden" name="business" value="MunicipioController">
<input type="hidden" name="action" value="salvar">


<input type="hidden" name="id" value="${objMunicipio.id}" /><br>
Nome:<input type="text" name="txtNome" value="${objMunicipio.nome}" /><br>
UF:<input type="text" name="txtUF" value="${objMunicipio.uf}" /> <br>
<input type="submit" value="Salvar" name="btnSalvar" />
<input type="reset" value="Limpar" name="btnLimpar" />
</form>

Observe os campos input com o tipo hidden. Hidden? Sim, escondidos. São campos como qualquer outro, mas você não os vê, pois não interessa ao usuário que esteja cadastrando o município. Porém, para nosso sistema é bem importante.

Ao enviar este formulário, note o endereço na barra do navegador, estes campos escondidos vão junto:
/ControllerServlet?business=MunicipioController&action=salvar&id=0&txtNome=Goiânia&txtUF=GO&btnSalvar=Salvar

Note que passamos com sucesso o controlador que tratará nossos dados (em business), bem como a ação desejado para nosso ControllerServlet (em action). Os dados de nosso formulário também estão aí, mas não são interessantes para o ControllerServlet. Só servirão para alguma coisa quando ele validar e instanciar o controlador correto para aqueles dados e depois repassar à ele. Aí sim, o controlador (MunicipioController neste caso) fará alguma coisa com estes dados.

E se tivéssemos que acrescentar outros tipos de dados (eg: Uf)? Teríamos o modelo para ele, bem como um controlador apropriado, que implementasse de BusinessLogic.

Nos formulários próprios do Uf, passaríamos a classe UfController como business, assim o ControllerServlet saberia para quem mandar a requisição: UfController. Note que os modelos/beans (retângulos traçejados) trabalham junto de seu respectivo controller.

Exemplo de novo registro de Uf:
/ControllerServlet?business=UfController&action=novo&id=0&txtSigla=GO&txtNome=Goiás&btnSalvar=Salvar

Bem, acho que a lógica do MVC está clara, né?
Na próxima parte do post falaremos de como isto tudo miraculosamente acontece a nível de código e simularemos o sistema sem precisar do NetBeans. :)

BR.

Fausto Junior