4. Desenvolvimento MVC (Modelo – Vista – Controlador)

Uma aplicação web tem frequentemente uma arquitetura de três camadas:

a camada [dao] encarrega-se do 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. Esta camada é independente de qualquer tipo de interface com o utilizador. Assim, deve poder ser utilizada tanto com uma interface de consola, como com uma interface web ou uma interface de cliente avançada. Deve, portanto, poder ser testada fora da interface web e, nomeadamente, com uma interface de consola. É geralmente a camada mais estável da arquitetura. Não se altera se se mudar a interface de utilizador ou a forma de aceder aos dados necessários ao funcionamento da aplicação.
a camada [interface utilisateur], que é a interface (frequentemente gráfica) que permite ao utilizador controlar a aplicação e receber informações da mesma.

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

o utilizador faz um pedido à camada [interface utilisateur]
esta solicitação é formatada pela camada [interface utilisateur] e transmitida à camada [métier]
Se, para processar este pedido, a camada [métier] precisar dos dados, solicita-os à camada [dao]
cada camada consultada envia a sua resposta à camada à sua esquerda, até à resposta final ao utilizador.

As camadas [métier] e [dao] são normalmente utilizadas através de interfaces Java. Assim, a camada [métier] apenas conhece, da camada [dao], a sua(s) interface(s) e não conhece as classes que as implementam. É isto que garante a independência das camadas entre si: alterar a implementação da camada [dao] não tem qualquer impacto na 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 – Vista – Controlador) insere-se na camada [interface utilisateur] quando esta é uma interface web:

O processamento de um pedido de um cliente decorre de acordo com as seguintes etapas:

o cliente envia um pedido ao controlador. Este recebe todos os pedidos dos clientes. É a porta de entrada da aplicação. É o C de MVC.
o controlador C processa essa solicitação. Para tal, pode necessitar da ajuda da camada de negócio. Uma vez processada a solicitação do cliente, esta pode dar origem a várias respostas. Um exemplo clássico é:
- uma página de erros, caso a solicitação não tenha podido ser processada corretamente
- uma página de confirmação, caso contrário
o controlador escolhe a resposta (= vista) a enviar ao cliente. Escolher a resposta a enviar ao cliente requer várias etapas:
- escolher o objeto que irá gerar a resposta. É o que se denomina a vista V, o V de MVC. Esta escolha depende, em geral, do resultado da execução da ação solicitada pelo utilizador.
- fornecer-lhe os dados de que necessita para gerar essa resposta. Com efeito, esta contém, na maioria das vezes, informações calculadas pelo controlador. Estas informações constituem o chamado 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 a mesma.
O controlador C solicita que a vista escolhida seja apresentada. 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, designaremos por «vista» tanto o objeto que gera a resposta para o cliente como a própria resposta. A literatura MVC não é explícita quanto a este ponto. Se fosse a resposta que se devesse chamar de vista, poderíamos chamar de gerador de vista o objeto que gera essa resposta.
O gerador de vista 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 desta 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 simples JDK e as bibliotecas básicas de desenvolvimento web. Um método que pode ser utilizado para aplicações simples é o seguinte:

o controlador é assegurado por um único servlet. É 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 utilizador. Para tal, se necessário, recorre à camada [métier].
Dependendo do resultado da execução, o método [doAction] determina qual a página JSP a apresentar. Trata-se da vista V do modelo MVC.
A página JSP contém elementos dinâmicos que têm de ser fornecidos pelo servlet. O método [doAction] irá fornecer esses elementos. Trata-se do modelo da vista, o M de MVC. Este modelo é normalmente 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 estes três contextos.
O método [doAction] exibe a vista, transferindo o fluxo de execução para a página JSP selecionada. Para tal, utiliza uma instrução do tipo [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)].

Este padrão de arquitetura (Design Pattern) MVC é denominado «Front Controller» ou ainda padrão de controlador único. Um único servlet processa todos os pedidos de todos os utilizadores.

Voltemos à arquitetura da aplicação web anterior:

Esta arquitetura corresponde à seguinte arquitetura n-tier:

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

Para aplicações simples, esta arquitetura é suficiente. Quando se desenvolvem várias aplicações deste tipo, verifica-se que os servlets de duas aplicações diferentes:

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

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

fatorizar o processamento (1) numa servlet genérica, alheia à aplicação que a utiliza
delegar o processamento (2) a classes externas, uma vez que a servlet genérica não sabe em que aplicação está a ser utilizada
estabelecer a ligação entre a ação solicitada pelo utilizador e a classe que deve processá-la, com a ajuda de um ficheiro de configuração

Surgiram ferramentas, frequentemente denominadas «frameworks», para proporcionar essas facilidades aos programadores. 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). Este 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. A 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.