P>

imagem.JPG

Clique aqui para ler todos os artigos desta edição

 

Construindo uma aplicação Web completa com o Spring Framework 2.0

A segunda parte da série de artigos sobre o Spring Framework

Na edição anterior conhecemos os conceitos básicos do Spring Framework. Agora vamos aplicar estes conceitos em um exemplo prático. Nesta edição veremos como construir uma aplicação Web utilizando duas das mais importantes contribuições do Spring: o framework MVC e o gerenciamento da camada de persistência. Quem já for familiarizado com frameworks como o Struts ou o JSF (JavaServer Faces) não terá problemas para entender o funcionamento básico do Spring Web MVC, afinal todos seguem o mesmo princípio. Para aqueles que desconhecem estas tecnologias, apresentamos uma introdução aos conceitos básicos de um framework MVC no tópico a seguir. Os únicos conhecimentos exigidos são a familiaridade com Servlets, JSP (Java Server Pages) e JSTL (Java Standard Tag Library).

Para a camada de persistência, o Hibernate foi a nossa opção. Mostraremos aqui como a sua integração com o Spring pode simplificar a vida dos desenvolvedores ao retirar a necessidade de implementação de todo aquele código de infra-estrutura. Ou seja, o programador deixa de se preocupar em ter que instanciar um SessionFactory, abrir e fechar Sessions, fazer o controle de transações e até mesmo com o lançamento de exceções.

O framework MVC do Spring

A utilização de frameworks MVC para o desenvolvimento de aplicações Web é bastante popular atualmente, especialmente na comunidade Java. O seu objetivo é a aplicação do padrão arquitetural MVC (Model View Controller) ao modelo de construção de websites dinâmicos. Isto significa separar o código em três partes bem definidas. São elas:

·         Model: representa o código de domínio da aplicação, onde estão os dados e regras de negócio;

·         View: é a interface com usuário, representada pelas telas do sistema;

·         Controller: responsável pela integração entre as outras partes. Ela recebe os eventos da View, chama os elementos da camada Model para processar e envia o resultado de volta para a View.

 

Com estas definições, podemos fazer uma transposição direta para o mundo de nossos programas Web em Java. Nesta plataforma, a camada View é geralmente representada por páginas JSP, a camada Model é composta pelas classes responsáveis pelo negócio (JavaBeans, EJBs, DAOs, classes de serviço, etc.) e a camada de controle é composta por classes definidas a partir dos pontos de extensão disponibilizados pelo framework MVC que for escolhido. O framework atua no sentido de prover a comunicação entre as camadas View e Controller, que é sem dúvida a área que precisa de mais cuidados no desenvolvimento de aplicações Web.

O Spring Web MVC tem como elemento central a classe DispatcherServlet. O seu objetivo é redirecionar as requisições HTTP para as classes handler que foram configuradas para recebê-las. Assim como qualquer outro servlet, ele precisa ser definido no Web Application Development Descriptor, o arquivo web.xml dentro da pasta WEB-INF do seu contexto Web. Na Listagem 1 mostramos como isto é feito. Na linha 3 demos o nome “dispatcher” para o DispatcherServlet e, para carregá-lo junto com o contexto, definimos na linha 5 a tag “load-on-startup”. Da linha 8 à linha 11 fizemos o mapeamento de nosso servlet para todas as URLs que seguem o padrão “*.htm”.

O padrão escolhido não é obrigatório. Poderia ter sido outro como “*.do” ou “/spring/*”. O que importa é apenas definir qual é o conjunto de URLs que devem ser atendidas pelo servlet. A partir deste momento, uma URL como “/sistema/index.htm” representa somente um caminho virtual que estará mapeado no framework MVC para um handler. Este handler pertence à camada Controller do padrão e é definido no Spring como uma classe Java que implementa a interface org.springframework.web.servlet.mvc.Controller.

O mapeamento destes handlers é realizado através de um arquivo XML que é carregado pelo DispatcherServlet. Este arquivo precisa estar dentro da pasta WEB-INF do contexto e ter o nome seguindo o modelo:

 

-servlet.xml

 

Dessa forma, para o caso do servlet definido na Listagem 1, devemos nomear o arquivo de “dispatcher-servlet.xml”. A estrutura deste arquivo é exatamente a mesma de qualquer arquivo de configuração do Spring, ou seja, um conjunto de “BeanDefinitions” assim como vimos no primeiro artigo desta série. Isto é muito bom para nós, pois não teremos que aprender um novo conjunto de tags para poder escrevê-lo.

O arquivo de configuração do DispatcherServlet é responsável por carregar basicamente três tipos de objetos:

·         ViewResolver: define a forma como o framework irá localizar uma View;

·         HandlerMapping: faz o mapeamento entre URLs e handlers;

·         Controller: representa o handler propriamente dito. É a implementação da camada de controle do padrão MVC.

 

Listagem 1. Configuração do DispatcherServlet no arquivo web.xml

1.     

2.        

3.          dispatcher

4.          org.springframework.web.servlet.DispatcherServlet

5.          1

6.        

7.       

8.        

9.          dispatcher

10.      *.htm

11.    

12. 

 

No artigo anterior, vimos a importância da programação baseada em interfaces. O framework MVC do Spring está totalmente de acordo com esta idéia. Os três objetos que acabamos de ver estão especificados como simples interfaces de modo que possam existir diferentes implementações para cada um deles capazes de serem carregadas de forma transparente pelo framework. Dentro do JAR do Spring já existem algumas implementações disponíveis, mas nada impede que qualquer programador crie as suas próprias. A finalidade disso é dar uma grande flexibilidade ao desenvolvedor na hora de montar o sistema, permitindo que ele escolha a opção que for mais adequada.

Na grande maioria dos casos, as Views são páginas JSP. Isto tira a necessidade de extensão das interfaces ViewResolver e HandlerMapping, pois o framework já provê classes específicas para este tipo de View. O mesmo não acontece com a interface Controller. Devido a sua característica de buscar dados da camada Model para enviar à View, estas classes tornam-se dependentes do domínio do problema, fazendo com que sempre seja preciso fornecer uma implementação.

Na Listagem 2 mostramos a definição básica do arquivo dispatcher-servlet,xml. Podemos ver que o ViewResolver (linha 3 a 7) e o HandlerMapping (linha 9) foram configurados como classes do próprio Spring. O primeiro define que a View será localizada aplicando um prefixo e um sufixo na string retornada pelo Controller. Isso fica mais claro quando observamos o exemplo da Listagem 3. Na linha 10 podemos ver que o Controller define uma string “index” para indicar a View que deve ser exibida. Assim, o ViewResolver irá localizar e passar para o DispatcherServelt a página “/WEB-INF/jsp/index.jsp”. Para o HandlerMapping, definimos um objeto da classe BeanNameUrlHandlerMapping. Isto significa que o mapeamento será realizado de modo que o nome do Controller definido no XML seja a URL responsável por invocá-lo. Na linha 11 da Listagem 2 podemos ver como um Controller deve ser configurado de acordo com este método de mapeamento.

 

Listagem 2. dispatcher-servlet.xml.

1.     xml version="1.0" encoding="UTF-8"?>

1.     <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

2.      

3.     <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">

4.         <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />

5.         <property name="prefix" value="/WEB-INF/jsp/" />

6.         <property name="suffix" value=".jsp" />

7.     bean>

8.      

9.     <bean id="defaultHandlerMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping" />

10.  

11. <bean name="/index.htm" class="br.com.wm.exemplo.MeuControllerSimples"/>

...

Quer ler esse conteúdo completo? Tenha acesso completo