4. Desenvolvimento MVC (Modelo – Visão – Controlador)

Uma aplicação web costuma ter uma arquitetura de três camadas:

a camada [dao] é responsável pelo acesso aos dados, na maioria das vezes dados persistentes dentro de um SGBD. Mas também podem ser dados provenientes de sensores, da rede, etc.
a camada [metier] implementa os algoritmos “de negócio” da aplicação. Essa camada é independente de qualquer tipo de interface com o usuário. Assim, ela deve ser utilizável tanto com uma interface de console quanto com uma interface web ou uma interface de cliente avançada. Portanto, deve poder ser testada fora da interface web e, em particular, com uma interface de console. Geralmente, é a camada mais estável da arquitetura. Ela não se altera se a interface do usuário for modificada ou se a forma de acesso aos dados necessários ao funcionamento da aplicação for alterada.
a camada [interface utilisateur], que é a interface (geralmente gráfica) que permite ao usuário controlar o aplicativo e receber informações dele.

A comunicação ocorre da esquerda para a direita:

o usuário faz uma solicitação à camada [interface utilisateur]
essa solicitação é formatada pela camada [interface utilisateur] e transmitida à camada [métier]
se, para processar essa solicitação, a camada [métier] precisar dos dados, ela os solicita à camada [dao]
cada camada consultada retorna sua resposta à camada à sua esquerda, até que a resposta final chegue ao usuário.

As camadas [métier] e [dao] são normalmente utilizadas por meio de interfaces Java. Assim, a camada [métier] conhece da camada [dao] apenas sua(s) interface(s) e não conhece as classes que as implementam. É isso que garante a independência das camadas entre si: alterar a implementação da camada [dao] não tem qualquer impacto sobre a camada [métier], desde que não se altere a definição da interface da camada [dao]. O mesmo se aplica às camadas [interface utilisateur] e [métier].

A arquitetura MVC (Modelo – Visão – Controlador) está inserida na camada [interface utilisateur] quando esta é uma interface web:

O processamento de uma solicitação de um cliente ocorre de acordo com as seguintes etapas:

o cliente faz uma solicitação ao controlador. Este recebe todas as solicitações dos clientes. É a porta de entrada do aplicativo. É o C de MVC.
o controlador C processa essa solicitação. Para isso, ele pode precisar da ajuda da camada de negócios. Uma vez processada a solicitação do cliente, ela pode gerar diversas respostas. Um exemplo clássico é:
- uma página de erros, caso a solicitação não tenha sido processada corretamente
- uma página de confirmação, caso contrário
o controlador escolhe a resposta (= vista) a ser enviada ao cliente. Escolher a resposta a ser enviada ao cliente envolve várias etapas:
- escolher o objeto que irá gerar a resposta. É o que chamamos de vista V, o V de MVC. Essa escolha depende, em geral, do resultado da execução da ação solicitada pelo usuário.
- fornecer a ele os dados necessários para gerar essa resposta. De fato, ela contém, na maioria das vezes, informações calculadas pelo controlador. Essas informações formam o que chamamos de modelo M da vista, o M de MVC.
- A etapa 3 consiste, portanto, na escolha de uma vista V e na construção do modelo M necessário para ela.
O controlador C solicita que a vista escolhida seja exibida. Na maioria das vezes, trata-se de executar um método específico da vista V encarregado de gerar a resposta para o cliente. Neste documento, chamaremos de vista tanto o objeto que gera a resposta para o cliente quanto a própria resposta. A literatura MVC não é explícita nesse ponto. Se fosse a resposta que deveria ser chamada de “vista”, poderíamos chamar de “gerador de vista” o objeto que gera essa resposta.
O gerador de visualização V utiliza o modelo M preparado pelo controlador C para inicializar as partes dinâmicas da resposta que deve enviar ao cliente.
A resposta é enviada ao cliente. A forma exata dessa resposta depende do gerador de visualização. Pode ser um fluxo HTML, PDF, Excel, ...

A metodologia de desenvolvimento web MVC não requer necessariamente ferramentas externas. Assim, é possível desenvolver uma aplicação web Java com uma arquitetura MVC utilizando apenas um JDK e as bibliotecas básicas de desenvolvimento web. Um método utilizável para aplicações simples é o seguinte:

o controle é assegurado por um único servlet. Esse é o C de MVC.
Todas as solicitações do cliente contêm um atributo “action”, por exemplo (http://.../appli?action=liste).
Dependendo do valor do atributo “action”, o servlet executa um método interno do tipo [doAction(...)].
O método [doAction] executa a ação solicitada pelo usuário. Para isso, se necessário, ele utiliza a camada [métier].
Dependendo do resultado da execução, o método [doAction] determina qual página JSP deve ser exibida. Essa é a vista V do modelo MVC.
A página JSP possui elementos dinâmicos que devem ser fornecidos pelo servlet. O método [doAction] fornecerá esses elementos. Trata-se do modelo da vista, o M de MVC. Esse modelo é geralmente colocado no contexto da solicitação (request.setAttribute("chave", "valor")), ou, com menos frequência, no contexto da sessão ou da aplicação. Uma página JSP tem acesso a esses três contextos.
O método [doAction] exibe a visualização, transferindo o fluxo de execução para a página JSP selecionada. Para isso, ele utiliza uma instrução do tipo [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)].

Esse padrão de arquitetura (Design Pattern) MVC é chamado de padrão “Front Controller” ou ainda padrão de controlador único. Um único servlet processa todas as solicitações de todos os usuários.

Voltemos à arquitetura da aplicação web anterior:

Essa arquitetura corresponde à seguinte arquitetura n-tier:

Na verdade, há apenas uma camada: a da interface web. De modo geral, uma aplicação web MVC baseada em servlets e páginas JSP terá a seguinte arquitetura:

Para aplicativos simples, essa arquitetura é suficiente. Ao desenvolver vários aplicativos desse tipo, percebe-se que os servlets de dois aplicativos diferentes:

possuem o mesmo mecanismo para determinar qual método [doAction] deve ser executado para processar a ação solicitada pelo usuário
na verdade, diferem apenas pelo conteúdo desses métodos [doAction]

A tentação, então, é grande de:

fatorar o processamento (1) em um servlet genérico que não tem conhecimento da aplicação que o utiliza
delegar o processamento (2) a classes externas, já que o servlet genérico não sabe em qual aplicação está sendo utilizado
estabelecer a ligação entre a ação solicitada pelo usuário e a classe que deve processá-la por meio de um arquivo de configuração

Ferramentas, frequentemente chamadas de “frameworks”, surgiram para oferecer essas facilidades aos desenvolvedores. O mais antigo e provavelmente o mais conhecido deles é o Struts (http://struts.apache.org/). O Jakarta Struts é um projeto da Apache Software Foundation (www.apache.org). Esse framework é descrito em (http://tahe.developpez.com/java/struts/).

Surgido mais recentemente, o framework Spring (http://www.springframework.org/) oferece funcionalidades semelhantes às do Struts. Sua utilização foi descrita em vários artigos (http://tahe.developpez.com/java/springmvc-part1/).

Apresentamos agora um exemplo de arquitetura MVC baseada em servlets e páginas JSP.