Framework MVC: Apache Struts ou JavaServer Faces? parte 2, por Givanildo Santana do Nascimento

Olá Pessoal,

Desculpa a demora, vamos retornar a 2º Parte do artigo anterior :
Framework MVC: Apache Struts ou JavaServer Faces?

Vamos lá...

Apache Struts Web Application Framework

O projeto do framework Struts foi iniciado em maio de 2000 por Craig R. McClanahan, com o objetivo de constituir uma implementação MVC padrão para a comunidade Java. Em julho de 2001 a versão 1.0 foi lançada e em pouco tempo o objetivo foi alcançado, havendo hoje inúmeras aplicações baseadas neste framework. Atualmente, os engenheiros da Apache Software Foundation estão trabalhando na versão 2 do Struts, o que mostra que ao contrário do que muitos imaginaram, o projeto do Struts não vai estagnar, ou mesmo descontinuar, por causa do JavaServer Faces.

Baseadas na arquitetura MVC, aplicações Struts têm três categorias de componentes: (1) componentes de controle, incluindo um servlet e um processador de requisições; (2) JavaServer Pages e Tag Libraries da camada de visão e (3) componentes de negócios e de acesso a dados da camada de modelo. A figura 4 ilustra a arquitetura de uma aplicação MVC baseada no Struts.

Figura 4. Arquitetura do Struts

Fonte: http://otn.oracle.com/sample_code/tutorials/bc4jvsm/struts/impl.htm

Além do MVC, o Struts adere a uma série de outros padrões e boas práticas, de forma transparente para quem o está utilizando. A figura 5 mostra os principais padrões seguidos pelo Struts.

Figura 5. Principais padrões seguidos pelo Struts

Fonte: Java One 2004 – TS-0227

O controlador Struts

Segundo o padrão Front Controller, o elemento de controle centralizado de uma aplicação MVC intercepta as requisições dos clientes – navegadores Internet no caso de aplicações WEB – seleciona e executa a lógica de negócios apropriada e redireciona a requisição para o próximo passo no fluxo da aplicação. Este próximo passo pode ser uma outra ação a ser interceptada pelo controlador ou uma página JSP, por exemplo, para a apresentação da resposta final à requisição do cliente. No Struts, o principal elemento de controle é o servlet org.apache.struts.action.ActionServlet. De forma bastante resumida, quando é iniciado, o ActionServlet lê do arquivo de configuração struts-config.xml os mapeamentos, chamados action mappings, das ações da aplicação. Estes mapeamentos são então usados pelo ActionServlet para transformar requisições HTTP em ações da aplicação.

As requisições são direcionadas ao ActionServlet graças a um mapeamento (servlet-mapping) definido no arquivo descritor da aplicação, o web.xml. É comum o uso do padrão *.do neste mapeamento, embora isto seja apenas uma convenção e não uma regra. A listagem 1 mostra um trecho do arquivo web.xml, responsável pela definição do ActionServlet e pelo seu mapeamento para o padrão convencional. O elemento <servlet> configura o ActionServlet, identificando-o por “action”, enquanto o elemento <servlet-mapping> associa o servlet “action” ao padrão *.do.

Listagem 1. Definição do ActionServlet do Struts no web.xml

JavaServer Faces

Em maio de 2001, um grupo de empresas reuniu-se no Java Community Process e propôs a Java Specification Request (JSR) 127, com o objetivo de definir uma arquitetura para o desenvolvimento de interfaces de usuário processadas no servidor, à qual foi dado o nome de JavaServer Faces (JSF). No dia 1º de março de 2004, a JSR 127 foi aprovada com 100% de aceitação entre os votantes, como mostra a tabela 1.

Tabela 1 – Resultado da votação da JSR-127

A proposta da tecnologia JSF é adicionar a facilidade de desenvolvimento de interfaces à robusta plataforma J2EE. O JSF simplifica o desenvolvimento de sofisticadas interfaces de usuário, definindo um modelo de componentes e eventos associado a um eficiente ciclo de processamento de requisições. Seus principais elementos são:
a) Um conjunto de componentes de interface e uma API para extensão e criação de novos componentes, gerenciamento de seu estado e de seus eventos;
b) Duas tag libraries com componentes de interface Web e de manipulação de objetos no lado servidor.

Para que o JSF cumpra seu papel de promover a produtividade, ele deve ser usado com o auxílio de um ambiente integrado de desenvolvimento (IDE) que ofereça suporte aos seus componentes e arquivos de configuração. A manipulação de componentes JSF em uma boa IDE proporciona simplicidade no desenvolvimento de interfaces Web semelhantes às que estão disponíveis no desenvolvimento para desktop. A IDE deve permitir que as páginas sejam visualmente preenchidas por componentes visuais, selecionados em paletas de compoentes, arrastados para dentro delas e tendo suas propriedades iniciais configuradas em tempo projeto.

JavaServer Faces e a arquitetura MVC

Aderência do JSF à arquitetura MVC ocorre de forma similar à do Swing e de outros frameworks de interface gráfica para desktop. A figura 6 mostra os elementos JSF na arquitetura MVC.

Figura 6. JSF na arquitetura MVC

Fonte: (Bergsten, 2004, p. 7).

Na camada de visão, os componentes são produzidos por classes Renderers,para apresentação em um mecanismo de saída. Um conjunto de Renderers correlacionados forma um RenderKit. A implementação JSF de referência inclui somente um RenderKit voltado para clientes HTML, o qual produz tags HTML para cada componente JSF. Com o passar do tempo, novos RenderKits serão desenvolvidos, permitindo que os componentes JSF possam convertidos para outras linguagens de marcação como WML e XML.]

Os componentes JSF definem eventos padrão, como o “valor alterado”, “botão clicado”, e permitem que novos manipuladores de eventos (listeners) sejam acoplados. Para aplicações Web, o JSF fornece um servlet de controle para o processamento de requisições, o javax.faces.webapp.FacesServlet, ou simplesmente FacesServlet. O FacesServlet é o correspondente JSF ao ActionServlet do Struts. Ele intercepta as requisições e aciona a camada de negócios, como preceitua o padrão Front Controller. Os eventos, manipuladores de eventos, o arquivo XML de configuração do JSF e o FacesServlet formam a camada de controle do JSF.
A navegação entre páginas de uma aplicação JSF determina que página será exibida em resposta a um evento acionado pelo usuário. As regras de navegação são definidas no arquivo de configuração da aplicação JSF, o faces-config.xml, em elementos <navigation-rule>, como mostra a listagem 2, e são manipuladas pelo gerenciador de navegação do JSF, acionado pelo FacesServlet. Cada elemento <navigation-rule> corresponde a uma página identificada pelo atributo opcional <from-view-id>. Quando este atributo não é informado, a regra é válida para todas as páginas da aplicação.

Listagem 2. Definição de regras de navegação.

As requisições são direcionadas ao FacesServlet graças a um mapeamento (servlet-mapping) definido no web.xml. É comum o uso dos padrões *.faces e /faces/*. A listagem 3 mostra um trecho do arquivo web.xml, responsável pela definição do FacesServlet e pelo seu mapeamento para o padrão /faces/*.

Listagem 3. Definição do FacesServlet no web.xml

Bom Pessoal, chegamos ao fim da parte 2 do nosso artigo.

Proxima semana estarei disponibilizando a 3º e última parte sobre : Framework MVC: Apache Struts ou JavaServer Faces?

Abraços e um bom fim de semana.