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

Uma aplicação web tem frequentemente uma arquitetura de 3 camadas:

a camada [DAO] lida com o acesso aos dados, na maioria das vezes dados persistentes dentro de um SGBD. Mas estes também podem ser dados provenientes de sensores, da rede, etc.
a camada [business] implementa os algoritmos «de negócio» da aplicação. Esta camada é independente de qualquer forma de interface de utilizador. Assim, deve ser utilizável com uma interface de consola, uma interface web ou uma interface de cliente avançada. Deve, portanto, ser testável fora da interface web, particularmente com uma interface de consola. Esta é geralmente a camada mais estável da arquitetura. Não se altera se a interface de utilizador ou o método de acesso aos dados necessários para o funcionamento da aplicação forem alterados.
A camada [da interface do utilizador], que é a interface (frequentemente gráfica) que permite ao utilizador controlar a aplicação e receber informações da mesma.

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

o utilizador faz um pedido à camada [interface do utilizador]
esta solicitação é formatada pela camada [interface do utilizador] e transmitida à camada [lógica de negócio]
se a camada [lógica de negócio] precisar de dados para processar esta solicitação, ela solicita-os à camada [DAO]
cada camada consultada devolve a sua resposta à camada à sua esquerda até que a resposta final chegue ao utilizador.

As camadas [negócio] e [DAO] são normalmente acedidas através de interfaces Java. Assim, a camada [negócio] conhece apenas a(s) interface(s) da camada [DAO] e desconhece as classes que as implementam. É isto que garante a independência das camadas umas das outras: alterar a implementação da camada [DAO] não tem impacto na camada [negócio], desde que a definição da interface da camada [DAO] permaneça inalterada. O mesmo se aplica entre as camadas [interface do utilizador] e [negócio].

A arquitetura MVC (Modelo–Visão–Controlador) é implementada na camada [interface do utilizador] quando se trata de uma interface web:

O processamento de um pedido do cliente segue estes passos:

O cliente envia uma solicitação ao controlador. O controlador lida com todas as solicitações do cliente. É o ponto de entrada da aplicação. É o C em MVC.
O controlador C processa esta solicitação. Para tal, pode necessitar da assistência da camada de negócios. Uma vez processada a solicitação do cliente, esta pode desencadear várias respostas. Um exemplo clássico é:
- uma página de erro, 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 enviar ao cliente. A escolha da resposta a enviar ao cliente envolve várias etapas:
- selecionar o objeto que irá gerar a resposta. Isto é chamado de vista V, o V em MVC. Esta escolha depende geralmente do resultado da execução da ação solicitada pelo utilizador.
- fornecer-lhe os dados de que necessita para gerar esta resposta. Com efeito, esta resposta contém, na maioria das vezes, informações calculadas pelo controlador. Estas informações constituem o que se denomina o modelo M da vista, o M em MVC.
- A etapa 3 consiste, portanto, em selecionar uma vista (V) e construir o modelo (M) necessário para ela.
O controlador C instrui a vista selecionada a apresentar-se. Isto envolve normalmente a execução de um método específico da vista V responsável por gerar a resposta para o cliente. Neste documento, referir-nos-emos tanto ao objeto que gera a resposta para o cliente como à própria resposta como sendo a vista. A literatura sobre MVC não é explícita neste ponto. Se fosse a resposta a ser chamada de vista, poderíamos chamar ao objeto que gera esta resposta o gerador de vista.
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 sua forma exata depende do gerador de visualização. Pode ser um fluxo HTML, PDF, Excel, etc.

A metodologia de desenvolvimento web MVC não requer necessariamente ferramentas externas. Assim, uma aplicação web Java com uma arquitetura MVC pode ser desenvolvida utilizando um JDK simples e bibliotecas básicas de desenvolvimento web. Um método adequado para aplicações simples é o seguinte:

O controlador é gerido por um único servlet. Este é o C em MVC.
Todos os pedidos 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, recorre à camada [business], se necessário.
Dependendo do resultado da execução, o método [doAction] decide qual a página JSP a apresentar. Esta é a View (V) no modelo MVC.
A página JSP contém elementos dinâmicos que devem ser fornecidos pelo servlet. O método [doAction] fornecerá esses elementos. Este é o modelo de visualização, o M em MVC. Este modelo é mais frequentemente colocado no contexto da solicitação (request.setAttribute("key", "value"), 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] renderiza a vista, passando o fluxo de execução para a página JSP selecionada. Para tal, utiliza uma instrução como [getServletContext() .getRequestDispatcher("página JSP").forward(request, response)].

Este padrão de design MVC é chamado de padrão "Front Controller" ou padrão de controlador único. Um único servlet lida com todos os pedidos de todos os utilizadores.

Voltemos à arquitetura da aplicação web anterior:

Esta arquitetura corresponde à seguinte arquitetura de n camadas:

Na verdade, existe apenas uma camada: a camada 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 já tiver escrito várias aplicações deste tipo, perceberá que os servlets de duas aplicações diferentes:

utilizam o mesmo mecanismo para determinar qual o método [doAction] a executar para tratar a ação solicitada pelo utilizador
na verdade, diferem apenas no conteúdo desses métodos [doAction]

A tentação é então forte de:

fatorizar o processamento (1) num servlet genérico que não tem conhecimento da aplicação que o utiliza
delegar o processamento (2) a classes externas, uma vez que o servlet genérico não sabe em que aplicação está a ser utilizado
vincular a ação solicitada pelo utilizador à classe que deve processá-la, utilizando um ficheiro de configuração

Surgiram ferramentas, frequentemente chamadas de «frameworks», para fornecer aos programadores estas capacidades. A mais antiga e provavelmente a mais conhecida delas é 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/).

O framework Spring (http://www.springframework.org/), que surgiu mais recentemente, 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 uma arquitetura MVC baseada em servlets e páginas JSP.