Java Simples

Java + FLEX Parte 3 -> Spring BlazeDS Integration + dpHibernate

Felipe Saab — Sat, 06 Aug 2011 18:21:04 +0000

Neste post iremos ver como obter ainda mais produtividade no desenvolvimento de aplicações Java + FLEX adicionando o framework dpHibernate ao nosso projeto da Agenda, que foi criado na Parte 1 e melhorado na Parte 2 dessa série.

Para utilizarmos o dpHibernate com todo o seu potencial precisaremos melhorar um pouco mais a nossa agenda pois até agora temos apenas uma entidade no projeto: o Contato. Iremos adicionar a entidade Pessoa, sendo assim, Contato passará a ser uma entidade filha de Pessoa. Em outras palavras: uma Pessoa poderá ter nenhum ou muitos Contatos.

Mas vamos a um pouco de teoria antes (caso você já conheça o dpHibernate pode pular para a parte onde a ação começa a acontecer hehehe):

O QUE É dpHibernate?

De acordo com o site do projeto:

dpHibernate is a custom Flex Library and a custom BlazeDS Hibernate adapter that work together to give you support for lazy loading of hibernate objects from inside your flex applications.

dpHibernate é uma biblioteca para projetos Flex e um adaptador customizado do BlazeDS com suporte para o Hibernate que trabalham juntos para proporcionar suporte a lazy loading de objetos hibernate a partir da sua aplicação flex.

Quer dizer, o dpHibernate é composto por dois projetos: uma biblioteca que será referenciada no projeto FLEX (um arquivo .swc) e outra biblioteca que vai ser referenciada no projeto Java (arquivo .jar) que vão proporcionar o lazy loading de objetos do hibernate a partir da sua aplicação FLEX!!

Vamos facilitar ainda mais com um exemplo:

Vamos pensar nas entidades que vamos utilizar daqui a pouco: Pessoa e Contato.

Na classe Pessoa nós vamos ter uma lista de Contato:

public class Pessoa {
 
    // Outros atributos
 
    @OneToMany(fetch=FetchType.LAZY, ...)
    private List contatos;
 
    // Getters e setters
 
}

Se antes de enviarmos uma Pessoa do Java para o FLEX não executarmos o método getContatos() do objeto Pessoa a lista não será inicializada pois está marcada para ser carregada preguiçosamente (FetchType.LAZY), e consequentemente não será enviada para o FLEX.

OBS: isso acontece porque estamos utilizando o Spring BlazeDS Integration no nosso projeto, e ele possui essa funcionalidade, somente listas inicializadas são enviadas para o FLEX.

Mas o que acontece caso eu queira a lista de contatos no FLEX? Ou inicializamos a lista antes de enviar o objeto para o FLEX, ou seja, executar o getter da lista, ou então quando precisarmos da lista no FLEX nós fazemos mais uma chamada remota para carregar a lista.

Pensando em performance o correto é carregar a lista somente quando realmente precisarmos dela, quando abrir a tela dos contatos por exemplo.

E é exatamente esta a função do dpHibernate! A primeira vez que uma lista for acessada (na aplicação FLEX) o dpHibernate vai verificar se essa lista já foi carregada ou não e caso ela não tenha sido ele irá se encarregar de fazer uma chamada remota para carregá-la. Tudo isso de uma maneira completamente transparente para o programador!

Agora que já sabemos como o dpHibernate funciona vamos preparar a nossa agenda adicionando a entidade Pessoa.

ADICIONANDO A ENTIDADE PESSOA

Na Parte 2 fizemos uma agenda que funcionava em torno de apenas uma entidade: Contato. Ou seja, tinhamos um DAO e um Service para o Contato. Tudo era relacionado com Contato.

Agora vamos adicionar um relacionamento ao contato, vamos seguir o seguinte diagrama de classes:

Com isso a nossa aplicação não vai mais girar em torno de Contato, e sim em torno de Pessoa, ou seja, ao invés de um DAO e um Service para Contato, eles serão para Pessoa. Como Contato passou a ser uma entidade filha, ela vai ser gerenciada através do “seu pai”, a pessoa.

Como essa alteração vai ocupar um bom espaço aqui do post eu sugiro que baixe as classes (e o ddl para o banco) que utilizaremos como base.

Aproveitei e dei uma arrumada no layout da nossa aplicação, agora ela está assim:

Muito bem, agora que a aplicação já está com um relacionamento podemos partir para a parte interessante do post, configurar o dpHibernate!

CONFIGURANDO O dpHibernate

A primeira coisa a se fazer é baixar as bibliotecas. Elas podem ser pegas através do site do projeto ou podem ser pegas aqui no Java Simples.

Por que pegar as bibliotecas aqui? Pois eu corrigi um pequeno probleminha no projeto (descrito nesse link). O problema que acontece na última versão disponível do projeto é na deserialização de identificadores (o id da entidade) do tipo java.lang.Long, o deserializador do projeto se confunde e tenta converter o valor vindo do FLEX para o tipo java.lang.Integer. Apliquei um pequeno patch disponibilizado por um dos commiters do projeto e tudo passou a funcionar perfeitamente, portanto caso você – assim como eu – utilize o tipo java.lang.Long para os identificadores sinta-se a vontade para baixar as bibliotecas já corrigidas ou para aplicar o patch no projeto (os códigos fonte podem ser pegos através da página do projeto).

OBS: no pacote de bibliotecas disponíveis aqui no blog também estão algumas bibliotecas adicionais necessárias para o correto funcionamento do projeto.

Com as bibliotecas baixadas basta adicionar os arquivos .jar no classpath do projeto Java e o arquivo .swc ao classpath do projeto FLEX.

Mãos à obra então!

Vamos começar alterando nossas entidades (classes do modelo). Para permitir que as classes sejam monitoradas pelo dpHibernate precisamos fazer apenas algumas alterações nelas: as classes Java devem estender HibernateProxy e sobrescrever o método getProxyKey() retornando um identificador único (o id funciona muito bem não? hehe) e as classes AS devem esternder HibernateBean e receber o metadado [Managed].

Pessoa.java

/**
 * Clase que representa uma pessoa na agenda.
 * Cada pessoa poderá ter vários {@link Contato contatos} (email, telefone,
 * site, ...).
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "PESSOA")
public class Pessoa extends HibernateProxy {
 
	private static final long serialVersionUID = 3815773591498770002L;
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	@Column(name = "ID", length=11, nullable=false)
	private Long id;
 
	@Column(name = "NOME", nullable = false, length = 100)
	private String nome;
 
	@OneToMany(fetch = FetchType.LAZY, mappedBy = "pessoa", cascade = CascadeType.ALL, orphanRemoval = true)
	private List contatos;
 
	@Override
	public Object getProxyKey() {
        	return id;
	}
 
	// Getters e Setters e outros métodos
 
}

Contato.java

/**
 * Classe que representa um contato de uma {@link Pessoa pessoa} na agenda.
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "CONTATO")
public class Contato extends HibernateProxy {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "ID", length = 11, nullable = false)
	private Long id;
 
	@Column(name = "TIPO", length = 50, nullable = false)
	private String tipo;
 
	@Column(name = "CONTATO", length = 100)
	private String contato;
 
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "ID_PESSOA", referencedColumnName = "ID")
	private Pessoa pessoa;
 
	@Override
	public Object getProxyKey() {
		return id;
	}
 
	// Getters e Setters e outros métodos
 
}

Pessoa.as

[Managed]
[RemoteClass(alias="br.blog.javasimples.agenda.model.Pessoa")]
public class Pessoa extends HibernateBean
{
	public var id:Number;
	public var nome:String;
	public var contatos:ArrayCollection;
 
	public function Pessoa()
	{
	}
 
	public function addContato(contato:Contato):void
	{
		if (!contatos)
		{
			contatos = new ArrayCollection();
		}
		contatos.addItem(contato);
		contato.pessoa = this;
		contatos.refresh();
	}
 
	public function removeContato(contato:Contato):void
	{
		if (!contatos) return;
		var index:int = contatos.getItemIndex(contato);
		if ( index == -1 ) return;
		contatos.removeItemAt(index);
		contatos.refresh();
	}
}

Contato.as

[Managed]
[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
public class Contato extends HibernateBean
{
	public var id:Number;
	public var tipo:String;
	public var contato:String;
	public var pessoa:Pessoa;
 
	public function Contato()
	{
	}
}

Modelo preparado, podemos partir então para a configuração da aplicação web e do Spring:

A estrutura de pastas e arquivos da aplicação web ficou assim:

Passamos a ter 3 arquivos de configuração do Spring: WEB-INF\spring\applicationContext.xml, WEB-INF\spring\persistence-config.xml e WEB-INF\spring\flex-config.xml. Mas vamos entendê-los mais a fundo nas próximas linhas, vamos começar do começo:

web.xml


 
	
 
		org.springframework.web.context.ContextLoaderListener
 
	
 
		contextConfigLocation
		/WEB-INF/spring/applicationContext.xml
 
	
 
		openSessionInViewFilter
		org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
 
	
 
		springMessageBroker
		org.springframework.web.servlet.DispatcherServlet
		1
 
			contextConfigLocation
			/WEB-INF/spring/flex-config.xml
 
	
 
		openSessionInViewFilter
		/*
 
		springMessageBroker
		/messagebroker/*

No deployment descriptor (vulgo web.xml hehehe) definimos que o Spring vai inicializar um container para a aplicação através do listener ContextLoaderListener, que o Hibernate vai ter somente uma sessão aberta durante toda a vida da nossa aplicação (isso é essencial para o lazy loading funcionar corretamente) através do filtro OpenSessionInViewFilter, e por fim definimos o DispatcherServlet do Spring MVC requerido pelo Spring BlazeDS Integration (como vimos na Parte 2).

Com isso já achamos onde são usados 2 arquivos de configuração do Spring: o applicationContext.xml vai conter os beans que poderão ser acessados de qualquer lugar da aplicação pois estarão no contexto da aplicação (ApplicationContext) e o flex-config.xml que é arquivo de configuração para o DispatcherServlet vai conter as configurações do Spring BlazeDS Integration.

OBS: caso não se lembre do servlet DispatcherServlet ou caso não conheça o Spring MVC eu sugiro que dê uma olhada no post: Spring Framework Parte 5 -> Spring Web MVC.

Vamos por partes então, primeiro o applicationContext.xml:

E de cara já vimos onde é utilizado o último arquivo de configuração, essa foi rápida né! hehehe

Os maiores motivos para a separação dos arquivos de configuração foi para eles ficarem mais legíveis e coesos, sendo assim o arquivo WEB-INF\spring\persistence-config.xml vai conter somente os beans relacionados à persistência dos dados. Para carregar esses beans no contexto da aplicação utilizamos a tag , com isso todos os beans que estiverem dentro do arquivo persistence-config.xml também serão carregados no contexto da aplicação.

Mas no applicationContext.xml além da inclusão dos beans relacionados à persistência foram definidas também as tags responsáveis por permitir a injeção de dependência e o gerenciamento dos Services e DAOs através de anotações.

persistence-config.xml


 
	
 
			com.mysql.jdbc.Driver
 
			jdbc:mysql://localhost:3306/javasimples_agenda
 
			usuario
 
			senha
 
	
 
		
 
				br.blog.javasimples.agenda.model
 
		
 
				org.hibernate.dialect.MySQL5InnoDBDialect
				true
				true

Apesar do arquivo ser um pouco grande não há muita coisa a ser dita sobre esses beans, foram definidos um DriverManagerDataSource para conversar com o banco de dados, a SessionFactory responsável pelo mapeamento do Hibernate e o HibernateTransactionManager responsável pelas transações das operações do Hibernate.

Dando continuidade aos arquivos de configuração vamos ver os beans que serão definidos no escopo do DispatcherServlet do Spring BlazeDS Integration:

flex-config.xml


 
	
 
	
 
	
 
				{
				"dpHibernate" :
				{
				"serializerFactory" : "org.dphibernate.serialization.SpringContextSerializerFactory"
				}
				}

Aqui é onde a mágica do dpHibernate acontece! hehehe

Começando de cima para baixo temos:

A injeção de dependência nesse contexto (DispatcherServlet) também poderá ser utilizada com anotações graças à tag , definimos o MessageBroker (não lembra dele? dê uma lidinha rápida na Parte 1 então) através da tag e definimos que o adaptador utilizado para processar as requisições será o dpHibernateRemotingAdapter (definido imediatamente abaixo).

Após o adaptador é definido o dataAccessService que vamos utilizar para cuidar das operações CRUD e do lazy loading das nossas entidades, com isso os nossos services vão conter apenas as regras de negócio envolvidas nas entidades, nada mais de CRUD nos services!

OBS: a tag é responsável por explicitamente definir o bean como um destination para o FLEX, ou seja, quando criarmos um RemoteObject podemos definir o destination = dataAccessService e essa classe (org.dphibernate.services.SpringDataAccessService) vai receber as requisições.

Logo em seguida é definida uma classe responsável por cachear os objetos serializados para evitar que eles sejam serializados mais de uma vez (assunto meio paralelo, então deixa pra outra hora.. heheh) e o serializador e o deserializador utilizados para converter os objetos Java para AMF e vice versa.

Depois temos o objectChangeUpdater que – de um jeito muito inteligente – cuida de todo o CRUD das entidades gerenciadas pelo dpHibernate. Aconselho fortemente a fazer checkout do código fonte e dar uma olhada.

E por fim temos o hiberanteProxyResolver, classe responsável por manter a integridade dos objetos que ele vai proxiar entre as diversas operações que realizar. Toda classe gerenciada pelo dpHiberante possui uma proxyKey, tanto que sobrescrevemos o getter dessa chave nas entidades para garantir que seja retornado sempre um valor único. O dpHibernate utiliza essa chave para saber qual objeto foi enviado do FLEX para o Java e utilizar o objeto que já estava na sessão do hibernate, mantendo assim a integridade dos dados. Bem simples e bem legal não?

Bom, é isso! Com isso terminamos de configurar o dpHibernate do lado servidor da nossa aplicação. Vamos passar então para o lado do cliente, a aplicação FLEX:

AgendaF.mxml

Nossa aplicação sofreu uma pequena mudança apenas para ter a interface melhorada, foram adicionados dois ícones na grid: um para mostrar os contatos e outro para remover a pessoa. Ambas funcionalidades serão vistas no próximo tópico, vamos nos atentar primeiro à configuração do dpHibernate.

É na função onApplicationComplete que nós faremos a única configuração no projeto FLEX: vamos criar um Service padrão para o dpHibernate poder utilizar para as operações CRUD. Isso é feito criando um HibernateRemoteObject que vai enviar as requisições para o service que definimos no contexto do DispatcherServlet: o dataAccessService.

E pronto! Java e FLEX configurados!!

SALVAR, ATUALIZAR E APAGAR REGISTROS

Vamos então utilizar as vantagens desse mundo de configurações né… hehehehe

Repare no código do arquivo AgendaF.mxml (listagem anterior) que quando o usuário clicar no botão Salvar será chamada a função salvaPessoa():

/**
 * Salva uma pessoa.
 */
private function salvaPessoa():void
{
	var pessoa:Pessoa=new Pessoa();
	pessoa.nome=txtNome.text;
	pessoa.contatos=new ArrayCollection();
 
	var token:AsyncToken=pessoa.save();
	token.addResponder(new mx.rpc.Responder(salvaPessoaSucesso, erro));
}
 
/**
 * Pessoa salva com sucesso.
 */
private function salvaPessoaSucesso(event:ResultEvent):void
{
	Alert.show("Pessoa salva com sucesso!");
 
	// Recupera a agenda com todas as pessoas
	this.getAgenda();
}

Para salvar ou atualizar (save ou update) uma entidade gerenciada pelo dpHiberante devemos apenas chamar a sua função save(). Ela funciona do mesmo modo que uma chamada a um método remoto, ou seja, retorna um AsyncToken referente à chamada para podermos saber se houve sucesso ou erro durante sua execução.

Se repararmos no código do botão da grid referente a apagar a pessoa veremos que ele chama a função apagaPessoa():

/**
 * Apaga a pessoa e seus contatos.
 */
public function apagaPessoa(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var token:AsyncToken=pessoa.deleteRecord();
		token.addResponder(new mx.rpc.Responder(apagaPessoaSucesso, erro));
	}
}
 
/**
 * Pessoa apagada com sucesso.
 */
private function apagaPessoaSucesso(event:ResultEvent):void
{
	Alert.show("Pessoa apagada com sucesso!");
 
	// Recupera a agenda com todas as pessoas
	this.getAgenda();
}

Do mesmo modo que a função save() as entidades gerenciadas pelo dpHibernate passam a ter também a função deleteRecord() que é um tanto quanto intuitiva certo? hehehe Apaga do banco a entidade que chamou a função.

E com isso terminamos o cadastro básico de Pessoa, vamos agora colocar os contatos na aplicação:

Contatos.mxml

O formulário de contatos segue o mesmo padrão do de pessoa: ao clicar no botão salvar é criado um novo Contato, adicionado na lista de contatos da pessoa e então a pessoa é salva novamente para persistir o novo contato no banco (em cascata); para remover um contato nós apenas o removemos da lista de contatos da pessoa e o apagamos do banco. Simples assim!

Para mostrar a tela de contatos, perceba que quando o botão referente a essa função for clicado ele vai chamar a função mostraContatos():

/**
 * Abre uma nova janela com os contatos da pessoa selecionada.
 */
public function mostraContatos(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var formContatos:Contatos=new Contatos();
		formContatos.pessoa=pessoa;
		PopUpManager.addPopUp(formContatos, this, true);
		PopUpManager.centerPopUp(formContatos);
	}
}

Criamos o formulário de contatos, passamos a pessoa que vai ter os contatos exibidos para dentro dele e por fim o adicionamos na tela utilizando o PopUpManager.

LAZY LOADING

Mas no fim das contas, como funciona o lazy loading que nós nem vimos acontecer? hehehehe

Repare na grid que mostra os contatos:

O dataProvider da grid é o atributo contatos do objeto pessoa. Quando o formulário está sendo carregado e a grid executa o primeiro get no atributo o dpHibernate já se encarrega de fazer uma chamada remota para carregar os contatos.

Quando utilizamos atributos que irão ser carregados preguiçosamente (lazy loading) no MXML (como na grid) não precisamos nos preocupar com absolutamente nada, o FLEX e o dpHibernate se encarregam de tudo. Mas e quando precisamos utilizar tais atributos no AS (em uma função)?

Todo objeto que sofre lazy loading dispara o evento LazyLoadEvent. Tal evento possui 3 tipos:

LazyLoadEvent.pending: é disparado antes de fazer a chamada remota que carregará o objeto;

LazyLoadEvent.failed: é disparado quando ocorre uma falha no processo de carregamento do objeto;

LazyLoadEvent.complete: é disparado quando o carregamento foi concluído, ou seja, a chamada remota retornou com os dados e o objeto já foi atualizado com tais dados.

Então vamos fazer uma pequena alteração na função que abre o formulário de contatos para ver se isso verdade:

/**
 * Abre uma nova janela com os contatos da pessoa selecionada.
 */
public function mostraContatos(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var formContatos:Contatos=new Contatos();
		if (pessoa.contatos.length &gt; 0)
			pessoa.contatos.getItemAt(0).addEventListener(LazyLoadEvent.complete, formContatos.contatosCarregados);
		formContatos.pessoa=pessoa;
		PopUpManager.addPopUp(formContatos, this, true);
		PopUpManager.centerPopUp(formContatos);
	}
}

Tudo bem, concordo que não é um código muito bonito… hehehe Mas como vimos a pouco, quem dispara o evento é o objeto que vai ser carregado preguiçosamente, sendo assim precisamos acessar algum desses objetos para poder colocar um listener nele. Devemos sempre ter certeza de que existe pelo menos um contato a ser carregado para poder acessá-lo e colocar um listener nele pois caso não fizéssemos a verificação antes e tentássemos abrir o formulário de contatos para uma pessoa que não tem nenhum contato nós iriamos receber um erro em tempo de execução.

Devemos sempre tomar muito cuidado ao programar as funções em AS, qualquer errinho vai estourar uma mensagem não muito agradável para o usuário final.

Dando continuidade, o listener que adicionamos foi para chamar a função contatosCarregados() do formulário de contatos, vamos a ela então:

/**
 * Mostra uma mensagem avisando que os contatos foram carregados.
 */
public function contatosCarregados(event:LazyLoadEvent):void
{
	Alert.show("A lista de contatos foi carregada com sucesso!");
}

Com isso, a primeira vez que abrirmos o formulário de contatos de uma pessoa que possua pelo menos um contato a ser carregado iremos receber a mensagem:

CARREGAMENTO EM LOTES (BATCH LOADING)

Uma última coisa (e não menos importante) para fecharmos esse post: carregamento em lotes.

Sem muita teoria, vou demonstrar com exemplos pois vai ser muito mais facil de entender né.

Eu criei uma pessoa e adicionei 3 contatos a ela, na próxima vez que eu entrar no sistema e abrir o formulário de contatos dela e seus contatos forem carregados reparem na saída impressa no console (ou arquivos de log) do tomcat:

{operation})****************loadBean
{deserialize} 0
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 10
{serialize} 1
{operation})****************loadBean
{deserialize} 1
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 15
{serialize} 0
{operation})****************loadBean
{deserialize} 0
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 1
{serialize} 1

Cada vez que o dpHibernate imprime {operation})*********nome_da_operacao quer dizer que chegou uma chamada remota! Repare que até tem quanto tempo levou para deserializar a chamada e para serializar a resposta.

Quer dizer, 1 chamada remota para carregar cada contato… Vamos e venhamos, isso não é muito eficiente né.

Para suprir esse problema o dpHibernate consegue trabalhar com lotes de requisições (explicados detalhadamente pelo criador neste post), ou seja, ao invés de uma requisição para cada contato, todas são agrupadas em um lote e são enviadas para o servidor em apenas uma chamada remota.

Para habilitar isso precisamos de mais uns ajustes nas configurações (coisa rápida, prometo!).

Vamos adicionar um novo bean no contexto do DispatcherServlet do Spring BlazeDS Integration (arquivo WEB-INF\spring\flex-config.xml):

E na função onApplicationComplete() onde definimos o service padrão para o CRUD do dpHibernate vamos indicar que ele deve começar a enviar as requisições em lotes:

/**
 * Inicializações gerais.
 */
protected function onApplicationComplete(event:FlexEvent):void
{
	var remoteObject:HibernateRemoteObject=new HibernateRemoteObject("dataAccessService");
	remoteObject.bufferProxyLoadRequests=true;
	HibernateManaged.defaultHibernateService=remoteObject;
	this.getAgenda();
}

E pronto! Ao rodar a aplicação novamente, abrir o formulário de contatos da pessoa que possui 3 contatos e observar o console (ou log) do tomcat veremos a seguinte saída:

{operation})****************loadProxyBatch
{deserialize} 6
Hibernate:
    select
        this_.ID as ID0_0_,
        this_.CONTATO as CONTATO0_0_,
        this_.ID_PESSOA as ID4_0_0_,
        this_.TIPO as TIPO0_0_
    from
        CONTATO this_
    where
        this_.ID in (
            ?, ?, ?
        )
{invoke} 219
{serialize} 5

Apenas uma requisição que já carregou os 3 contatos!

Agora sim a nossa aplicação está 100%! Bonita, funcional e eficiente!

Os projetos completos (incluindo as biliotecas) podem ser baixados aqui (20MB).

CONCLUSÃO

É isso ai pessoal, o post acabou ficando um pouco longo mas creio que se você leu até aqui não ficou decepcionado com o tempo gasto, certo? hehehe

Um ponto que vale a pena ser comentado é em relação ao nosso Service e nosso DAO de Pessoa, depois de implantar o dpHibernate no nosso projeto vamos ver como eles ficaram:

/**
 * Interface que define os métodos de um serviço para {@link Pessoa}.
 *
 * @author Felipe Saab
 */
public interface PessoaService {
 
	/**
	 * Recupera todas as pessoas da agenda.
	 *
	 * @return Todos as pessoas
	 */
	List getAgenda();
}

/**
 * Interface que define os métodos necessários para o DAO de Pessoa.
 *
 * @author Felipe Saab
 */
public interface PessoaDao {
 
	/**
	 * Recupera todas as pessoas da agenda.
	 *
	 * @return Todos as pessoas
	 */
	List getAgenda();
 
}

Como ficou simples! Sem os métodos referentes ao CRUD (tudo bem, ainda tem um select ai.. dá um desconto poxa.. heheh) o Service e o DAO passam a ter somente a regra de negócio referente a entidade pela qual são responsáveis. A aplicação acaba se tornando mais legível!

Olhando agora para a nossa aplicação e tudo o que fizemos nela desde a Parte 1 dessa série podemos ver que utilizamos vários frameworks para aumentar a nossa produtividade: Spring, Hibernate, Spring BlazeDS Integration e dpHibernate. Com isso conseguimos construir uma aplicação como esta agenda em poucas horas (chegaria em horas mesmo? hehehe), desde o banco de dados até a interface agradável para o usuário final.

O dpHibernate é um framework poderosíssimo (li em blogs que já foi utilizado para projetos de grande porte) e open source! Caso esteja curioso sobre como ele funciona basta fazer checkout no repositório SVN na página do projeto (o que eu aconselho fortemente) e fuçar… muito legal mesmo!

Espero que tenha gostado deste post, todos os feedbacks são importantes, não deixe de comentar por favor.

PS: Caso esteja desenvolvendo um projeto com o dpHibernate sinta-se a vontade para me procurar caso esteja passando por alguns problemas, já passei por vários e você não precisa passar por eles também. =]

[]s e até a próxima,
Saab.

REFERÊNCIAS

[1] Using the ItemRenderer with a DataGrid

[2] Explicitly mapping ActionScript and Java objects

[3] Steps for getting going with dpHibernate

[4] Serialization issue with using primitive type long

[5] Batch loading proxies in dpHibernate

xmlns=”http://java.sun.com/xml/ns/javaee” xmlns:web=”http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”
id=”WebApp_ID” version=”2.5″>

org.springframework.web.context.ContextLoaderListener

contextConfigLocation
/WEB-INF/applicationContext.xml

openSessionInViewFilter
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter

springMessageBroker
org.springframework.web.servlet.DispatcherServlet
1

openSessionInViewFilter
/*

springMessageBroker
/messagebroker/*

Java + FLEX Parte 2 -> Spring BlazeDS Integration + Hibernate

Felipe Saab — Thu, 23 Jun 2011 21:53:58 +0000

Fala pessoal, finalmente a parte 2 do tutorial da nossa integração Java + FLEX!

CONSIDERAÇÕES INICIAIS

Caso você não tenha visto a Parte 1 do tutorial, por favor, veja ou baixe a aplicação pois a refatoração será feita em cima do projeto desenvolvido no tutorial anterior.

INTRODUÇÃO

Até agora o que temos é uma aplicação com o objetivo de ser uma Agenda de Contatos, porém os contatos estão ficando apenas em memória (uma lista estática na classe ContatoService.java), ao parar o servidor e rodá-lo novamente os contatos anteriormente salvos sumiram.. Ok, para evitar isso vamos persistir os contatos em um banco de dados, e para facilitar ainda mais a nossa vida vamos utilizar o Hibernate para nem nos preocuparmos com SQL, mecher apenas com as classes.

OBS: Por favor não me entenda errado, saber SQL é extremamente importante!! Mesmo utilizando o Hibernate as vezes precisamos construir querys utilizando HQL ou mesmo SQL, mas como nossa aplicação é extremamente simples nós podemos deixar isso de lado e utilizar todas as facilidades que o Hibernate provê.

E tem também o Spring! Ele nos será útil por dois fatores:

Injeção de Dependência: vamos utilizar interfaces e anotações para o Spring injetar os beans que precisamos em cada classe. Por consequência melhorar muito o projeto (design) da nossa aplicação pois as classes ficarão desacopladas (pois utilizaremos as interfaces). Conforme formos escrevendo o código isso ficará mais claro.

Integração com o BlazeDS: vamos utilizar um framework que a SpringSource criou para a integração do Spring com o BlazeDS para não precisarmos de muitas configurações e para termos possibilidade de aproveitar todas as funcionalidades do Spring como segurança e mensagens por exemplo. Para entender melhor sobre este projeto recomendo a leitura da referência [1].

Vamos fazer as coisas por partes então: primeiro vamos adicionar o Spring ao nosso projeto e depois adicionaremos o Hibernate pois ele vai ser um bean gerenciado pelo Spring também.

DOWNLOADS

Spring Framework: Iremos precisar do Spring Framework (utilizarei o 3.1.0 M2) em si e de um outro projeto da SpringSource chamado Spring BlazeDS Integration projetado para facilitar a comunicação do Spring com o FLEX.

Hibernate: No momento em que estou escrevendo este post a última versão é a 3.6.5.

MÃO NA MASSA: SPRING

Vamos começar a escrever códigos então!

Hoje o serviço que o FLEX acessa para recuperar/adicionar os contatos é a classe ContatoService que tem todos os métodos já implementados. Vamos criar uma interface para este serviço para tornar a nossa aplicação mais desacoplada (para mais informação sobre interfaces e suas vantagens leia este post).

Vamos mudar o nome da classe ContatoService.java para ContatoServiceImpl.java e mudar ela de pacote também: vamos criar um novo pacote e movê-la para ele: br.blog.javasimples.agenda.service.impl.

Agora que a classe já está com o novo nome podemos criar a interface com o nome antigo (ContatoService.java) no pacote br.blog.javasimples.agenda.service (apenas por questões de padrão de nomenclatura). Sendo assim temos a seguinte estrutura:

A interface ContatoService apenas vai definir os métodos que um serviço para contatos deve ter:

/**
 * Interface que define os métodos de um serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
public interface ContatoService {
 
	/**
	 * Salva um contato.
	 *
	 * @param contato - {@link Contato} a ser salvo
	 */
	void salvar(Contato contato);
 
	/**
	 * Recupera todos os contatos.
	 *
	 * @return Todos os contatos
	 */
	List<contato> getAgenda();
}

E a classe ContatoServiceImpl.java agora deve implementar a interface:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * {@link List Lista} que guarda todos os contatos.
	 */
	private static List<contato> agenda = new ArrayList<contato>();
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		ContatoServiceImpl.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return ContatoServiceImpl.agenda;
	}
}

Legal, agora que o serviço já virou uma interface e tem sua implementação vamos adicionar as bibliotecas do Spring no nosso projeto.

As bibliotecas que precisamos estão em: {pasta de download do spring}/dist e {pasta de donwload do spring blazeds integration}/dist.

Fiz um pacote com algumas bibliotecas que o Spring utiliza e irão gerar erro caso não estejam no projeto. Adicione essas bibliotecas no classpath também.

Para adicionar as bibliotecas basta colar (CTRL + V) elas na pasta WebContent/WEB-INF/lib do projeto ContatosJ:

Vamos agora começar a mecher em algumas configurações:

WebContent/WEB-INF/web.xml

 version="1.0" encoding="UTF-8"?>
 xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
	version="2.4">
	>
		>spring>
		>org.springframework.web.servlet.DispatcherServlet>
		>
			>contextConfigLocation>
			>/WEB-INF/applicationContext.xml>
		>
		>1>
	>
	>
		>spring>
		>/messagebroker/*>
	>
>

Antes nós tinhamos o MessageBrokerServlet definido no nosso arquivo, porém com o projeto de integração entre BlazeDS e Spring nós não precisamos mais ter isso tão explícito, o próprio projeto (Spring BlazeDS Integration) se responsabiliza por criar o MessageBroker e fazer todas as configurações internamente.

Porém o pessoal que criou o projeto utilizou o Spring Web MVC internamente (aceitável né… hehehe), sendo assim, tudo o que precisamos fazer é criar um DispatcherServlet (controlador responsável por todas as requisições que chegam para o Spring Web MVC) e mapear todas as requisições que chegarem para o MessageBroker (/messageBroker/*) para ele, ou seja, toda vez que o FLEX enviar uma requisição para a nossa aplicação (a URL vai ser +/- assim: http://localhost:8080/AgendaJ/messageBroker/my-amf/…) ela vai ser encaminhada para o DispatcherServlet e ele por sua vez vai encaminhar para a classe que deve receber e tratar a requisição.

Vamos criar o arquivo de configuração do Spring em WebContent/WEB-INF/applicationContext.xml (pois informamos este caminho no DispatcherServlet definido no web.xml).

 version="1.0" encoding="UTF-8"?>
 xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:flex="http://www.springframework.org/schema/flex"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                           http://www.springframework.org/schema/context
                           http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/flex
                           http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
	
	 />
 
	
	 />
 
	
	 base-package="br.blog.javasimples.agenda.service.impl" />
 
>

Neste pequeno arquivo de configuração nós estamos definindo tudo que precisamos para fazer o Spring conversar com FLEX como se fosse por mágica! hehehe

Com a tag nós estamos pedindo para o Spring BlazeDS Integration criar o MessageBroker (a classe que vai receber as requisições através do DispatcherServlet que configuramos no web.xml).

A tag habilita a injeção de dependência através de anotações. Para que o Spring BlazeDS Integration consiga fazer com que a comunicação aconteça sem que nós fiquemos configurando muita coisa os Serviços que vão receber as chamadas remotas devem ser gerenciados pelo container do Spring. Para isso nós poderíamos declarar os beans de serviço no applicationContext.xml através da tag porém para cada novo serviço deveríamos fazer o mesmo. Para evitar isso utilizaremos a anotação @Service nas classes para fazer com que o Spring possa gerenciá-las. É equivalente à utilização da tag . Se você ainda não entendeu continue lendo que já já vai ficar claro.

E a tag fala para o container do Spring procurar no pacote br.blog.javasimples.agenda.service.impl por classes que estejam anotadas com @Service e com outras anotações que ele conhece para gerenciá-las, ou seja, para poder fazer injeção de dependência e para utilizá-las para comunicar com o FLEX.

Para terminarmos a parte de configuração do Spring vamos voltar e mecher na implementação do serviço de Contato adicionando algumas anotações nele:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Service
@RemotingDestination(value="contatoService")
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * {@link List Lista} que guarda todos os contatos.
	 */
	private static List<contato> agenda = new ArrayList<contato>();
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		ContatoServiceImpl.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return ContatoServiceImpl.agenda;
	}
}

A anotação @Service diz que a classe ContatoServiceImpl vai ser gerenciada pelo Spring, ou seja, ela vai estar presente no container do Spring, consequentemente ela vai conseguir ser acessada por injeção de dependência, e pelo Spring BlazeDS Integration (e qualquer outro lugar que precise dessa classe através do Spring).

E a anotação @RemotingDestination informa qual o id devemos utilizar no RemoteObject do FLEX para chamar os métodos desta classe. Simples assim!!!

Lembra que criamos uma tag no arquivo WebContent/WEB-INF/flex/remoting-config.xml informando o id e a classe? Agora não precisa mais, só essa anotação já resolve todos os problemas, faz com que o Spring BlazeDS Integration faça tudo sozinho por trás.

Com o Spring BrazeDS Integration tomando conta de criar e gerenciar todas as configurações que vamos precisar para a comunicação Java <-> FLEX podemos “fazer um limpa” nos arquivos de configuração do BlazeDS que nós não vamos utilizar ou que o Spring irá criar sozinho. Podemos apagar os arquivos WebContent/WEB-INF/flex/remoting-config.xml, WebContent/WEB-INF/flex/messaging-config.xml e WebContent/WEB-INF/flex/proxy-config.xml:

Agora vamos ajeitar o arquivo WebContent/WEB-INF/flex/services-config.xml para não referenciar mais os arquivos excluídos:

 version="1.0" encoding="UTF-8"?>
>
	>
		>
			 ref="my-amf" />
		>
	>
 
	>
		 class="flex.messaging.security.TomcatLoginCommand"
			server="Tomcat" />
	>
 
	>
		 id="my-amf"
			class="mx.messaging.channels.AMFChannel">
			
				url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"
				class="flex.messaging.endpoints.AMFEndpoint" />
		>
	>
 
	>
		 class="flex.messaging.log.ConsoleTarget" level="Error">
			>
				>[BlazeDS] >
				>true>
				>true>
				>true>
				>true>
			>
			>
				>Endpoint.*>
				>Service.*>
				>Configuration>
			>
		>
	>
 
	>
		>
			>true>
			>20>
			>{context.root}/WEB-INF/flex/services-config.xml>
			>{context.root}/WEB-INF/web.xml>
		>
	>
>

A grande alteração nesse arquivo foi na tag onde removemos as referências aos arquivos que acabamos de excluir e indicamos para o BlazeDS que o canal padrão para a comunicação é o canal my-amf, ou seja, todas as requisições que chegarem para o message-broker e não tiverem um canal em específico irão ser enviados para o canal my-amf.

OBS: também foram removidas as referências dos arquivos removidos da tag .

E com isso terminamos a configuração do Spring! Que maravilha não?!?! Valeu SpringSource por fazer esse projetinho show de bola!

ADICIONANDO O HIBERNATE

Uma vez que o Spring está configurado vamos para a persistência dos dados com o Hibernate.

Primeiro de tudo vamos criar um banco de dados para a nossa aplicação:

CREATE TABLE contato (
	id INT( 11 ) NOT NULL AUTO_INCREMENT,
	nome VARCHAR( 50 ) NOT NULL ,
	telefone VARCHAR( 14 ) NOT NULL ,
	email VARCHAR( 50 ) NULL ,
	PRIMARY KEY ( id )
) ENGINE = innodb CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Ok, agora precisamos das bibliotecas do Hibernate no classpath da nossa aplicação. Vamos adicionar as bibliotecas:
{pasta download hibernate}/hibernate3.jar
{pasta download hibernate}/lib/jpa
{pasta download hibernate}/lib/required
{pasta download hibernate}/lib/bytecode/javassist

E também precisamos da biblioteca que contém o driver do banco de dados que estamos utilizando (no meu caso a do MySQL).

Agora já podemos realizar o mapeamento objeto relacional da nossa classe Contato.java para a tabela Contato do banco de dados (eu gosto de mapear utilizando anotações, mas não tem problema nenhum utilizar xml):

/**
 * Classe que representa um Contato da agenda.
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "CONTATO")
public class Contato implements Serializable {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	@Column(name="ID", length=11, nullable=false)
	private Long id;
 
	@Column(name="NOME", length=50, nullable=false)
	private String nome;
 
	@Column(name="TELEFONE", length=14, nullable=false)
	private String telefone;
 
	@Column(name="EMAIL", length=50)
	private String email;
 
	public Long getId() {
		return id;
	}
 
	public void setId(Long id) {
		this.id = id;
	}
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getTelefone() {
		return telefone;
	}
 
	public void setTelefone(String telefone) {
		this.telefone = telefone;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
	@Override
	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("[");
		sb.append(this.getNome() + ",");
		sb.append(this.getTelefone() + ",");
		sb.append(this.getEmail());
		sb.append("]");
		return sb.toString();
	}
}

Foi adicionado o atributo id para representar a chave primária do contato.

Como também existe uma classe Contato no FLEX precisamos atualizá-la:

package br.blog.javasimples.agenda.model
{
	[Bindable]
	[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
	public class Contato
	{
		public var id:Number;
		public var nome:String;
		public var telefone:String;
		public var email:String;
 
		public function Contato()
		{
		}
	}
}

Vamos utilizar agora um padrão de projeto (design pattern) chamado DAO (Data Access Object): tal padrão visa centralizar o acesso aos dados em um único objeto, ou seja, sempre que precisarmos gravar/recuperar algo do banco de dados vamos utilizar os métodos desse objeto.

Do mesmo jeito que fizemos a interface ContatoService é interessante fazer a ContatoDao. Seguindo o padrão de nomenclarura dos pacotes vamos criá-la no pacote br.blog.javasimples.agenda.dao:

/**
 * Interface que define os métodos de um DAO para {@link Contato}.
 *
 * @author Felipe Saab
 */
public interface ContatoDao {
	/**
	 * Salva um contato.
	 *
	 * @param contato - {@link Contato} a ser salvo
	 */
	void salvar(Contato contato);
 
	/**
	 * Recupera todos os contatos.
	 *
	 * @return Todos os contatos
	 */
	List<contato> getAgenda();
}

Foram definidos os métodos que já estamos utilizando em ContatoService para acessar os dados para depois que o DAO estiver pronto nós apenas delegarmos a chamada do Service para DAO.

Vamos para a implementação então – sempre seguindo o padrão de nomenclatura dos pacotes: br.blog.javasimples.agenda.dao.impl.

/**
 * DAO para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Repository
public class ContatoDaoImpl extends HibernateDaoSupport implements ContatoDao {
 
	@Autowired
	public void init(SessionFactory sessionFactory) {
		super.setSessionFactory(sessionFactory);
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void salvar(Contato contato) {
		this.getHibernateTemplate().save(contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public List<contato> getAgenda() {
		return this.getHibernateTemplate().loadAll(Contato.class);
	}
 
}

A anotação @Repository funciona como a anotação @Service, ou seja, o container do Spring vai conseguir gerenciá-la dinamicamente por causa dessa anotação. Essa anotação também é utilizada para alguns tratamentos específicos para a camada de persistência de dados, mas não vem ao caso agora. heheh

O método init(SessionFactory) que é executado internamente após a classe ser instanciada serve para configurar a classe pai (HibernateDaoSupport) setando a SessionFactory nele. Esse método possui a anotação @Autowired pois antes dele ser executado o Spring vai injetar o atributo sessionFactory para nós (a classe estando anotada com @Repository demonstra que ela pode estar no container e o Spring vai conseguir injetar as dependências).

Porém essa nova classe precisa de mais algumas configurações no arquivo de configuração do Spring (applicationContext.xml) para poder funcionar:

 version="1.0" encoding="UTF-8"?>
 xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:flex="http://www.springframework.org/schema/flex"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                           http://www.springframework.org/schema/context
                           http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/flex
                           http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
	
	 />
 
	
	 />
 
	
	 base-package="br.blog.javasimples.agenda.service.impl" />
 
	
	 base-package="br.blog.javasimples.agenda.dao.impl" />
 
	
	 id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		 name="driverClassName">
			>com.mysql.jdbc.Driver>
		>
 
		 name="url">
			>jdbc:mysql://localhost:3306/javasimples_agenda>
		>
 
		 name="username">
			>usuario>
		>
 
		 name="password">
			>senha>
		>
	>
 
	
	 id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
 
		 name="dataSource">
			 local="dataSource" />
		>
 
		
		 name="packagesToScan">
			>
				>br.blog.javasimples.agenda.model>
			>
		>
 
		
		 name="hibernateProperties">
			>
				 key="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect>
				 key="hibernate.show_sql">true>
				 key="hibernate.format_sql">true>
			>
		>
	>
 
>

Adicionamos uma nova tag informando que o pacote onde vão estar os DAOs também deve ser gerenciado pelo Spring, definimos um DataSource (para saber mais leia este post) e definimos a SessionFactory (para saber mais leia este post) que vai ser injetada no método init(SessionFactory) da classe ContatoDaoImpl.

Uma vez que o DAO está criado e configurado corretamente precisamos mudar o ContatoServiceImpl para utilizá-lo ao invés da lista estática que utilizava antes:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Service
@RemotingDestination(value="contatoService")
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * DAO
	 */
	@Autowired
	private ContatoDao contatoDao;
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		this.contatoDao.salvar(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return this.contatoDao.getAgenda();
	}
}

Mais uma vez aproveitamos da facilidade da injeção de dependência através de anotações para não nos preocuparmos em instanciar/recuperar o objeto contatoDao, o Spring se encarrega disso para nós.

Prontinho, com isso nós acabamos de incrementar a nossa pequena agenda com Spring e Hibernate!

CONCLUSÃO

Se testarmos a aplicação com essas alterações veremos que ela continua funcionando exatamente da mesma maneira que estava funcionando antes porém agora com o Spring tomando conta da comunicação entre o Java e o FLEX e o Hibernate persistindo os contatos no banco, quando formos adicionar novas funcionalidades temos que pensar apenas na funcionalidade, não precisamos ficar nos preocupando com os detalhes mais baixo nível (como a comunicação Java + FLEX). Tenho uma palavra para isso: produtividade! hehehe

Todo esse processo que realizamos é mais conhecido como refatoração: não mudamos nada do ponto de vista do usuário, apenas melhoramos a estrutura interna do aplicativo.

O código fonte pode ser pego aqui (sem as bibliotecas).

[]s e até a próxima,

Saab.

REFERÊNCIAS

[1] An introduction to Spring BlazeDS Integration

[2] Simple Flex Webapp

[3] Página do projeto Spring BlazeDS Integration

[4] Using Spring BlazeDS Integration 1.0

PS: Gostou? Não gostou? Ajudou? Não ajudou? Quebrou um galho? Perdeu 10 minutos da tua vida lendo? Comente! Divulgue! Fale mal! Compartilhe sua opinião com toda a comunidade!

Java + FLEX Parte 1 -> Integrando Java e FLEX

Felipe Saab — Fri, 22 Apr 2011 23:39:00 +0000

Hoje iremos abordar uma integração (que eu particularmente acho) fantástica: Java e FLEX (cuja versão mais atual se chama Flash Builder 4).

A primeira grande (super, ultra, …) vantagem que me vem na cabeça quando falo deste assunto é a facilidade para criar belas interfaces. Eu sou uma negação quando o assunto é criar interfaces, design me dá arrepios…

Outro ponto que é um grande vantagem é que toda a interface roda em cima do Flash, ou seja, basta ter o flash instalado no navegador e é certeza que o programa vai abrir exatamente do jeito que você o projetou! Não dá pau de navegador pra navegador!!!! Quem meche com CSS sabe do que eu estou falando, tua página está perfeita no Firefox e quando abre ela no IE dá até medo. Hahahaha quem nunca passou por isso que atire a primeira pedra.

Enfim, veremos como é possível ter uma interface fácil de desenvolver e ao mesmo tempo amigável para o usuário final com um backend poderosíssimo rodando o nosso bom e (não tão) velho Java e todos os frameworks que estamos acostumados a usar, como Spring e Hibernate.

Esta série será dividida (a princípio) em 2 partes:

Parte 1 – Comunicação básica entre Java e FLEX
Parte 2 – Integrando Spring e Hibernate na nossa aplicação

Antes de começarmos propriamente dito com o tutorial deixe me falar como funciona essa integração: como o FLEX roda na máquina virtual do Flash que fica no browser (diferente do AIR que é desktop) a nossa aplicação Java também vai rodar em um servidor de aplicativos web (neste caso o Tomcat) para eles poderem se comunicar.

Ambos (FLEX e Java) rodando na web fazem com que o canal de comunicação fique na nossa cara: a própria WEB! Sendo assim, toda vez que o FLEX precisa se comunicar com o Java (quando o usuário manda salvar um objeto por exemplo) o FLEX envia uma mensagem (utilizando o protocolo AMF) para o Java através da WEB.

No servidor Java vai haver um servlet responsável por receber essas mensagens, decodificá-las, transformar os dados em objetos Java e encaminhar para a classe e método que tais objetos devem ser encaminhados e retornar o resultado para o FLEX.

Dita a teoria vamos a prática! hehehe

Vamos precisar ter algumas coisas instaladas:

Eclipse IDE
Flash Builder 4 Eclipse Plugin (Trial por 60 dias)
BlazeDS 4 (Site da Adobe) ou local

Caso você já tenha o Eclipse instalado em sua máquina basta informar o caminho para ele durante a instalação que ele já instalará todos os plugins necessários. Caso não tenha o Eclipse basta baixar uma versão do Flash Builder que já vem com uma versão da IDE (porém não é a mais recente).

Depois que tudo estiver instalado vamos começar importando a estrutura base do projeto Java que vem junto com o arquivo do BlazeDS. No Eclipse selecione o menu Arquivo > Importar e selecione Arquivo WAR na categoria Web.

Na próxima tela informe o caminho para o arquivo blazeds.war (que veio no arquivo do BlazeDS que você baixou) e informe o nome que o novo projeto vai ter. Iremos fazer uma simples (e bonita! hehe) agenda de contatos onde guardaremos os telefones e emails dos nossos amigos, então irei chamar o projeto de AgendaJ.

*OBS: Para o desenvolvimento Java + FLEX são criados 2 projetos: uma projeto Java e um projeto FLEX. Eu tenho o costume (e diria que é uma boa prática) de dar o mesmo nome aos dois projetos adicionando como sufixo J ou F caso o projeto seja Java ou FLEX, respectivamente.

Ok. Agora podemos dar uma espiada para ver como funciona toda a configuração da nossa aplicação Java. Vamos começar olhando para o deployment descriptor WebContent/WEB-INF/web.xml*:

*Apaguei os comentários que vieram junto com o arquivo pois não vamos utilizá-los.

>
	>BlazeDS>
	>BlazeDS Application>
 
	
	>
		>flex.messaging.HttpFlexSession>
	>
 
	
	>
		>MessageBrokerServlet>
		>MessageBrokerServlet>
		>flex.messaging.MessageBrokerServlet>
		>
			>services.configuration.file>
			>/WEB-INF/flex/services-config.xml>
		>
		>1>
	>
 
	>
		>MessageBrokerServlet>
		>/messagebroker/*>
	>
 
	>
		>index.html>
		>index.htm>
	>
>

Foi definido um servlet chamado MessageBrokerServlet da classe flex.messaging.MessageBrokerServlet que recebe o parâmetro services.configuration.file indicando qual é o arquivo que contém as configurações dos serviços do FLEX. Conseguimos ver também que o MessageBrokerServlet recebe todas as requisições que chegam para a URL “…/messagebroker/*”, ou seja, sempre que o FLEX envia uma requisição para o Java já sabemos que é seguindo este padrão de URL (caso ainda não esteja claro já já vai ficar ).

Olhando o arquivo de configuração dos serviços (WebContent/WEB-INF/flex/services-config.xml)* podemos observar que:

*Retirei alguns comentários e fiz alguns pequenos ajustes nesse arquivo.

ele inclui três outros arquivos de configuração através da tag dentro da tag ;
diz qual classe vai ser responsável pela segurança (autenticação e autorização) em um servidor de aplicativos J2EE;
define quais canais estarão disponíveis para a comunicação através da tag . Cada canal definido dentro desta tag indica o mapeamento de um padrão de URL para uma classe em específico, por exemplo, a classe flex.messaging.endpoints.AMFEndpoint irá receber todas as requisições que forem para a URL “…/messagebroker/amf”;
configura o Logging das comunicações;
configura o redeploy automático de alguns arquivos que ele fica “observando” em intervalos de tempo definidos.

>
    >
         file-path="remoting-config.xml" />
         file-path="proxy-config.xml" />
         file-path="messaging-config.xml" />
    >
 
    >
         class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
    >
 
    >
         id="my-amf" class="mx.messaging.channels.AMFChannel">
             url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
        >
 
         id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
             url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
            >
                >false>
            >
        >
 
         id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
             url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
            >
                >true>
                >4>
            >
        >
    >
 
    >
         class="flex.messaging.log.ConsoleTarget" level="Error">
            >
                >[BlazeDS] >
                >true>
                >true>
                >true>
                >true>
            >
            >
                >Endpoint.*>
                >Service.*>
                >Configuration>
            >
        >
    >
 
    >
        >
            >true>
            >20>
            >{context.root}/WEB-INF/flex/services-config.xml>
            >{context.root}/WEB-INF/flex/proxy-config.xml>
            >{context.root}/WEB-INF/flex/remoting-config.xml>
            >{context.root}/WEB-INF/flex/messaging-config.xml>
            >{context.root}/WEB-INF/web.xml>
        >
    >
>

OBS: perceba que todos os canais tem o padrão de URL parecido (“…/messagebroker/…”). Por isso que o MessageBrokerServlet recebe todas as requisições para a URL “…/messagebroker/*”, ele verifica para qual canal ela vai e encaminha para a classe correta.

Os outros arquivos de configuração não contém nada que precise chamar a atenção agora. Então já dá pra dizer que sabemos como o Java recebe e trata as requisições do FLEX!

Vamos preparar o backend da nossa aplicação então: vamos criar a classe que vai representar um contato da nossa agenda e um serviço para executar as regras de negócio da nossa aplicação:

Contato.java

public class Contato implements Serializable {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	private String nome;
 
	private String telefone;
 
	private String email;
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getTelefone() {
		return telefone;
	}
 
	public void setTelefone(String telefone) {
		this.telefone = telefone;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
	@Override
	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("[");
		sb.append(this.getNome()+",");
		sb.append(this.getTelefone()+",");
		sb.append(this.getEmail());
		sb.append("]");
		return sb.toString();
	}
}

A classe que representa um contato possui apenas o nome, telefone e email do contato. Suficiente para nossa pequena agenda.

OBS: essa classe implementa a interface java.io.Serializable pois ela vai trafegar na Web (do Java para o FLEX e vice versa). É aconselhavel que todo objeto que for ser transmitido através de um canal (socket, web, etc) implemente esta interface e tenha o serialVersionUID (que o Eclipse gerou pra mim hehe) que indica um número único para identificar aquela classe.

Vamos ver agora o serviço que irá tratar a inserção de novos contatos na nossa agenda:

ContatoService.java

public class ContatoService {
 
	private static List<contato> agenda = new ArrayList<contato>();
 
	public void salvar(Contato contato) {
		ContatoService.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	public List<contato> getAgenda() {
		return ContatoService.agenda;
	}
}

Como ainda não vamos utilizar o banco de dados e o Hibernate nesta parte do tutorial vamos simular um “banco de dados” (está entre aspas duplas tá.. hehehe) com uma lista estática.

O método salvar(Contato) simplesmente adiciona um novo contato na agenda e o método getAgenda() retorna a nossa agenda com todos os contatos.

Esses métodos vão ser utilizados para o FLEX pedir para o Java salvar um novo contato na agenda e para ele recuperar a agenda com os contatos atualizados.

Para finalizar o desenvolvimento do nosso backend precisamos apenas expor nossa classe de serviço para que as classes que recebem a requisição do FLEX (pacote flex.messaging.endpoint) consigam localizá-la em tempo de execução.

Para isso adicionaremos uma nova tag no arquivo WebContent/WEB-INF/flex/remoting-config.xml informando um ID para este novo destino e qual classe é responsável por tratar as requisições destinadas a ele. Desta maneira nós informaremos este mesmo ID no FLEX quando precisarmos chamar algum método desta classe.

 id="remoting-service" class="flex.messaging.services.RemotingService">
 
	>
		 id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true" />
	>
 
	>
		 ref="my-amf" />
	>
 
	 id="contatoService">
		>
			>br.blog.javasimples.agenda.service.ContatoService>
		>
	>
 
>

Agora já podemos deixar o Java um pouco de lado e ir pra parte nova: o FLEX!

Vamos criar um novo projeto no Eclipse: Arquivo > Novo > Projeto. Na categoria Flash Builder vamos escolher um Flex Project. Na primeira tela configuramos o nome do projeto (vou colocar AgendaF como já comentei lá em cima), dizemos que ele vai rodar na Web e vai se comunicar com um servidor J2EE utilizando o BlazeDS.

OBS: tenha certeza de que o checkbox “Create combined Java/Flex project using WTP” está DESMARCADO.

Na próxima tela informamos algumas configurações do servidor J2EE (no meu caso o Tomcat):

Root folder –> O caminho pra raiz da aplicação Java no disco;
Root URL –> O caminho para a raiz da aplicação Java através do servidor;
Context Root –> O contexto da aplicação no servidor;
Output Folder (o Eclipse sugere) –> Caminho para a pasta onde o projeto FLEX será compilado e ficará “guardado”. Fica dentro da raiz da aplicação Java pra ser executada junto com o servidor.

Na próxima tela temos que adicionar uma pasta que será a raíz dos códigos fonte. Na aba Source Path apenas clique em Add Folder… e crie uma nova pasta com o nome src.

Após criado o projeto temos mais um ajuste a fazer: caso o Flash Builder 4 que você tenha baixado veio na língua inglesa e seu sistema operacional esteja em português o Eclipse vai criar uma configuração em português (porque ele “reflete” o locale do SO) e o Flash Builder não vai se dar muito bem com ele não… hehehe

Para corrigir esse parâmetro vamos nas propriedades do projeto (botão direito no projeto > Propriedades) e na categoria Flex Compiler existe o campo de texto Additional compiler arguments onde está escrito “-services …\services-config.xml –locale pt_BR”. Vamos apenas trocar o parâmetro “-locale pt_BR” por “-locale en_US”.

Legal, vamos começar a programar mesmo. Mude a perspectiva do Eclipe para Flash (caso ainda não tenha o feito). Vamos entrar em outro mundo agora, vamos deixar o Java um pouco de lado e programar em ActionScript 3 (aka AS3), linguagem utilizada na plataforma FLEX (e outras da Adobe).

OBS: eu não vou entrar em detalhes da linguagem propriamente dita, uma vez que o nome do blog não é AS3 Simples.. kkkkkkkk Mas não tem diferenças muito grandes não, uma pessoa que está acostumada com Java consegue pegar o AS3 rapidinho.

Vamos começar criando a classe que representa um contato da agenda. Vamos criar um pacote com o mesmo nome do pacote no Java (outra boa prática) e criar uma ActionScript Class com o mesmo nome (Contato.as):

package br.blog.javasimples.agenda.model
{
	[Bindable]
	[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
	public class Contato
	{
		public var nome:String;
		public var telefone:String;
		public var email:String;
 
		public function Contato()
		{
		}
	}
}

A classe que representa o contato do lado do FLEX deve possuir os atributos com os mesmos nomes do nome de atributo extraído dos getters da classe Java. Estranho né… heheheh Vamos ver com um pequeno exemplo:

Na classe Contato.java eu tenho os getters getNome(), getTelefone() e getEmail(). Quando o BlazeDS vai enviar os dados do Java para o FLEX ele vai fazer um algorítmo que siga uma lógica parecida com essa (não olhei no código fonte pra saber se é assim mesmo, porém o resultado final é algo assim):

String getterName = "getEmail";
String attributeName = getterName.replaceFirst("get",""); // attributeName == "Email"
attributeName = attributeName.substring(0,1).toUpperCase() + attributeName.substring(1); // // attributeName == "email"

Ou seja, com os getters getNome(), getTelefone() e getEmail() o BlazeDS vai enviar os valores para a classe Contato.as esperando que existam os atributos nome, telefone e email.

O BlazeDS segue esse mesmo padrão para enviar os dados do FLEX para o Java, ou seja, os setters devem seguir esse mesmo padrão de nomenclatura.

Continuando com a nossa classe, algo novo para quem nunca usou AS3 são as anotações: [Bindable] e [RemoteClass(alias)].

Se essas anotações fossem em Java seriam: @Bindable e @RemoteClass(alias=”…”). Só a primeira vista que confunde um pouco, mas é a mesma coisa.

Segue o significado de tais anotações:

[Bindable] – é algo como a implementação do design pattern Observer. Todo lugar que estiver referenciando alguma propriedade dessa classe será imediatamente avisado assim que alguma delas sofrer alguma mudança;
[RemoteClasse(alias)] – indica para o BlazeDS qual a classe correspondente a essa na aplicação Java.

Tão simples quanto fazer um POJO no Java não?! hehehe

Agora vem a parte que me fascina no FLEX: layout!

Vamos abrir o arquivo AgendaF.mxml que o Eclipse gerou para nós. Ao mudar para a aba design nós podemos criar a nossa tela com um simples clicar e arrastar de componentes. Arrastei alguns componentes e mudei os labels e em menos de 10 minutos eu fiz o design da nossa aplicação de exemplo:

O código do arquivo AgendaF.mxml ficou assim:

 xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx">
 
     width="500">
         label="Nome" width="100%" direction="horizontal">
             id="txtNome" width="220"/>
             width="100%" height="10"/>
             label="Telefone" direction="horizontal">
                 width="100" id="txtTelefone"/>
            >
        >
         label="Email" width="100%" direction="horizontal">
             width="220" id="txtEmail"/>
             width="100%" height="10"/>
             label="Salvar"/>
        >
         width="100%">
             width="100%">
                >
                     headerText="Nome"/>
                     headerText="Telefone"/>
                     headerText="Email"/>
                >
            >
        >
    >
 
>

OBS: perceba que os TextInputs tem ids definidos. Isso para que possamos recuperar os seus valores via programação logo mais.

Para vermos como vai ficar esse layout no browser basta rodar o projeto AgendaJ primeiro e depois o AgendaF.

AgendaJ – botão direito no projeto > Run As > Run on Server
AgendaF – botão direito no projeto > Run As > Web Application

Vamos fazer isso funcionar agora!

Vamos começar com a funcionalidade de salvar um contato: toda vez que o botão Salvar for pressionado iremos criar um objeto Contato e enviar para o Java, mais especificamente para o método salvar(Contato) da classe ContatoService.

Para isso vamos precisar de uma área para programar em ActionScript dentro do arquivo AgendaF.mxml, que como o nome indica (e conseguimos ver através da aba Source) é um XML. Tal área fica disponível através da tag .

Segue o código que salva um novo contato:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx">
 
<fx:Script>
        [CDATA[
            import br.blog.javasimples.agenda.model.Contato;
 
            import mx.controls.Alert;
            import mx.rpc.AsyncToken;
            import mx.rpc.Responder;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.events.ResultEvent;
            import mx.rpc.remoting.RemoteObject;
 
            private var remoteObject:RemoteObject=new RemoteObject("contatoService");
 
            private function salvaContato():void
            {
                var contato:Contato=new Contato();
                contato.nome=txtNome.text;
                contato.telefone=txtTelefone.text;
                contato.email=txtEmail.text;
 
                // Insere esse contato na lista do Java
                var token:AsyncToken=remoteObject.salvar(contato);
                token.addResponder(new mx.rpc.Responder(salvarSucesso, erro));
            }
 
            private function salvarSucesso(result:ResultEvent):void
            {
                Alert.show(“Contato salvo com sucesso!”);
            }
 
            private function erro(event:FaultEvent):void
            {
                Alert.show("Ocorreu o seguinte erro: " + event.fault.faultString);
            }
 
        ]]>
    fx:Script>
 
   -- ..... -->
 
s:Application>

Vamos começar de cima para baixo:

Primeiro temos a declaração e instanciação de um objeto da classe RemoteObject. Essa classe é a responsável por fazer a comunicação com outra classe do lado do Java. Para criarmos esse vínculo basta passarmos o ID que definimos para a classe Java (no arquivo WebContent/WEB-INF/flex/remoting-config.xml) no construtor do RemoteObject.

No nosso caso a classe ContatoService.java está vinculada dentro da tag no arquivo remoting-config.xml então utilizamos este mesmo ID no construtor do nosso obejto.

Vamos olhar agora para o método salvaContato(): é criado um novo objeto Contato e seus dados são preenchidos com os valores dos TextInputs. Logo depois utilizamos o RemoteObject para invocar o método salvar(Contato) da classe a que ele está vinculado (ContatoService.java).

Para invocar os métodos remotos nós temos que imaginar que o RemoteObject é a classe que queremos utilizar (neste caso ContatoService). Exemplo: na classe ContatoService nós temos o método salvar(Contato). Para executar esse método através do RemoteObject basta executar um método com o mesmo nome e com os mesmos parâmetros (super usual né ).

Continuando, todas as chamadas a métodos remotos são assíncronas, ou seja, temos que esperar voltar uma resposta do Java para receber o retorno do método ou uma possível falha (caso seja jogada alguma Exception).

Para lidarmos com isso, todo método remoto executado através do RemoteObject retorna um AsyncToken. Através deste AsyncToken nós podemos ser notificados sempre que o método remoto retorna algo (o retorno do método ou uma exception).

Para isso nós adicionamos um Responder no AsyncToken. O construtor do Responder requer que passemos duas funções de parâmetro: a primeira será chamada quando o método remoto for concluído com sucesso e a segunda será chamada quando o método remoto jogar um erro.

A função que vai ser chamada quando o método remoto for concluído vai receber um ResultEvent como parâmetro (na grande maioria das vezes, porém não é regra) e caso o método remoto retornasse algum objeto nós conseguimos acessar esse retorno atavés do atributo result do objeto ResultEvent.

Já no caso da função que vai ser chamada quando o método remoto jogar um erro, ela recebe um FaultEvent (na maioria dos casos, porém também não é regra). E para acessar detalhes sobre o erro que foi jogado utilizamos o atributo fault do objeto FaultEvent.

Voltando para o nosso código, quando o método ContatoService.salvar(Contato) terminar de salvar o contato na lista nós exibiremos uma mensagem informando o usuário de que o novo contato foi salvo.

Ao executarmos o projeto e inserir um novo contato acontece o seguinte:

E se observarmos o console do Eclipse também vamos ver:

Porém a grid ainda continua vazia… Vamos configurá-la então:

Todos os registros que aparecem em uma DataGrid devem estar em um array, uma lista ou algo parecido (por hora um Array está ótimo! hehehe). O Array que contém os dados que serão mostrados na DataGrid deve alimentar o atributo dataProvider dela. Vamos então criar um Array e alimentar a nossa grid:

 xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx">
 
    >
        [CDATA[
            import br.blog.javasimples.agenda.model.Contato;
 
            import mx.collections.ArrayCollection;
            import mx.controls.Alert;
            import mx.rpc.AsyncToken;
            import mx.rpc.Responder;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.events.ResultEvent;
            import mx.rpc.remoting.RemoteObject;
 
            private var remoteObject:RemoteObject=new RemoteObject("contatoService");
 
            [Bindable]
            private var agenda:ArrayCollection=new ArrayCollection();
 
            private function salvaContato():void
            {
                var contato:Contato=new Contato();
                contato.nome=txtNome.text;
                contato.telefone=txtTelefone.text;
                contato.email=txtEmail.text;
 
                // Insere esse contato na lista do Java
                var token:AsyncToken=remoteObject.salvar(contato);
                token.addResponder(new mx.rpc.Responder(salvarSucesso, erro));
            }
 
            private function salvarSucesso(result:ResultEvent):void
            {
                Alert.show("Contato salvo com sucesso!");
            }
 
            private function erro(event:FaultEvent):void
            {
                Alert.show("Ocorreu o seguinte erro: " + event.fault.faultString);
            }
 
        ]]>
    >
 
     width="500">
         label="Nome" width="100%" direction="horizontal">
             id="txtNome" width="220"/>
             width="100%" height="10"/>
             label="Telefone" direction="horizontal">
                 width="100" id="txtTelefone"/>
            >
        >
         label="Email" width="100%" direction="horizontal">
             width="220" id="txtEmail"/>
             width="100%" height="10"/>
             label="Salvar" click="this.salvaContato()"/>
        >
         width="100%">
             width="100%" dataProvider="{this.agenda}">
                >
                     headerText="Nome" dataField="nome"/>
                     headerText="Telefone" dataField="telefone"/>
                     headerText="Email" dataField="email"/>
                >
            >
        >
    >
 
>

Foi criado um ArrayCollection chamado agenda e talvariável foi passada para o atributo dataProvider da DataGrid, sendo assim todos os elementos que estiverem dentro do ArrayCollection irão aparecer na grid também.

Indicamos também nas colunas qual atributo dos objetos que estão dentro do dataProvider deve ser exibido através do atributo dataField.

Tudo o que precisamos fazer agora é adicionar os nossos contatos nesse ArrayCollection agora. Vamos fazer o seguinte, toda vez que um novo contato for salvo nós iremos chamar o método getAgenda() da classe ContatoService e armazenar o retorno do método na variável agenda que acabamos de criar, assim manteremos a lista sempre atualizada e consequentemente a grid com todos os nossos contatos.

"1.0" encoding="utf-8"?>
 xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx">
 
    >
        [CDATA[
            import br.blog.javasimples.agenda.model.Contato;
 
            import mx.collections.ArrayCollection;
            import mx.controls.Alert;
            import mx.rpc.AsyncToken;
            import mx.rpc.Responder;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.events.ResultEvent;
            import mx.rpc.remoting.RemoteObject;
 
            private var remoteObject:RemoteObject=new RemoteObject("contatoService");
 
            [Bindable]
            private var agenda:ArrayCollection=new ArrayCollection();
 
            private function salvaContato():void
            {
                var contato:Contato=new Contato();
                contato.nome=txtNome.text;
                contato.telefone=txtTelefone.text;
                contato.email=txtEmail.text;
 
                // Insere esse contato na lista do Java
                var token:AsyncToken=remoteObject.salvar(contato);
                token.addResponder(new mx.rpc.Responder(salvarSucesso, erro));
            }
 
            private function salvarSucesso(result:ResultEvent):void
            {
                Alert.show("Contato salvo com sucesso!");
 
                // Recupera a lista completa
                var token:AsyncToken=remoteObject.getAgenda();
                token.addResponder(new mx.rpc.Responder(getAgendaSucesso, erro));
            }
 
            private function getAgendaSucesso(event:ResultEvent):void
            {
                this.agenda=event.result as ArrayCollection;
            }
 
            private function erro(event:FaultEvent):void
            {
                Alert.show("Ocorreu o seguinte erro: " + event.fault.faultString);
            }
 
        ]]>
    >
 
     width="500">
         label="Nome" width="100%" direction="horizontal">
             id="txtNome" width="220"/>
             width="100%" height="10"/>
             label="Telefone" direction="horizontal">
                 width="100" id="txtTelefone"/>
            >
        >
         label="Email" width="100%" direction="horizontal">
             width="220" id="txtEmail"/>
             width="100%" height="10"/>
             label="Salvar" click="this.salvaContato()"/>
        >
         width="100%">
             width="100%" dataProvider="{this.agenda}">
                >
                     headerText="Nome" dataField="nome"/>
                     headerText="Telefone" dataField="telefone"/>
                     headerText="Email" dataField="email"/>
                >
            >
        >
    >
 
>

Prontinho! Ao rodar a aplicação de novo e adicionar mais contatos conseguimos ver que agora tudo está funcionando perfeitamente!

Bom, confesso que este post ficou um pouco maior do que eu imaginei inicialmente… hehehe

Mas o importante é que deu pra passar a idéia sobre como funciona a integração do Java e do FLEX e como pessoas cujo dom na área de design não é muito elevado (como eu) podem fazer aplicações bonitas e amigáveis para o usuário final!

O código fonte desses projeto está disponível aqui.

Veja a parte 2 também..!

Na parte 2 vamos integrar o Spring e o Hibernate nesse nosso pequeno projeto e ficará muito claro como podemos conseguir uma produtividade incrível aliada com um resultado fantástico para o usuário utilizando essas tecnologias e esses frameworks.

[]s e até a próxima,

Saab.

PS: Gostou? Não gostou? Ajudou? Não ajudou? Quebrou um galho? Perdeu 10 minutos da tua vida lendo? Comente! Divulgue! Fale mal! Compartilhe sua opinião com toda a comunidade!

Java Magazine 90 – Hibernate Annotations

Felipe Saab — Thu, 21 Apr 2011 15:09:43 +0000

É com grande prazer que venho informar que escrevi um artigo sobre Hibernate Annotations para a revista Java Magazine e o artigo foi publicado na edição número 90.

Segue um pequeno resumo do artigo:

Hibernate Annotations – Mapeamento Objeto Relacional através de Anotações

Desde que surgiu o Hibernate para ser uma ponte entre a orientação a objetos e a persistência de dados em bancos de dados relacionais, tudo o que o desenvolvedor precisa fazer é descrever suas classes com alguns metadados para poder se focar no desenvolvimento da aplicação (regras de negócio). Assim, sem se preocupar muito com a persistência de seus objetos em bancos de dados o desenvolvedor consegue aumentar sua produtividade.

Durante um bom tempo os metadados foram descritos através de XML (e são até hoje). Para cada classe que seria persistida no banco de dados era criado um novo XML explicando como o Hibernate deveria realizar o mapeamento entre atributos da classe e colunas da tabela.

Atualmente este não é mais o único modo de descrever os metadados, existe também o Hibernate Annotations, projeto que provê a descrição dos metadados através de anotações. Deste modo, ao invés de um arquivo XML para cada classe, os metadados podem ser anotados na própria classe e em seus atributos, facilitando ainda mais o processo de mapeamento.

Nesse artigo serão apresentados os conceitos necessários para entender como utilizar o framework Hibernate para persistir as classes Java em bancos de dados relacionais apenas com a descrição de metadados providos por anotações, utilizando, para isso, a IDE NetBeans 6.9.1 e o banco de dados MySQL.

Caso o assunto seja de seu interesse pode dar um pulo no site da revista ou então dar uma conferida nas bancas..

[]s,
Saab.

PS: Isso não foi marketing! Estou feliz pois meu primeiro artigo para a revista foi publicado.

Spring Framework Parte 5 -> Spring Web MVC

Felipe Saab — Tue, 01 Feb 2011 00:28:19 +0000

Antes de entrar no assunto deixe-me dar aquele aviso de praxe: caso você não ainda não conheça o básico do Spring Framework dê uma olhadinha nos posts anteriores dessa série:

Beleza, já que você conhece o Spring vamos ao assunto de hoje: como o Spring implementa o padrão de projeto Model-View-Controller (MVC).

O MVC é um padrão de arquitetura de software que visa separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos (via Wikipedia).

A imagem acima descreve o fluxo das informações no padrão MVC:

1 – O usuário dispara um evento através da camada de visualização (clica em um botão na página ou algo do gênero);
2 – O controlador recebe o evento e coordena como as coisas vão acontecer do lado do servidor, ou seja, passa o fluxo para os objetos necessários para realizar a regra de negócio;
3 – O modelo é utilizado para representar o domínio das informações do negócio então ele é chamado pelo controlador para a realizar a regra de negócio que deve ser realizada. O modelo pode ainda ser usado para enviar os dados para a visão (camada onde o usuário vê as coisas acontecerem, uma página web por exemplo);
4 – Depois que o controlador realiza a regra de negócio utilizando o modelo ele renderiza a nova visão e a envia para o usuário. Criar uma aplicação utilizando o padrão MVC nada mais é do que separar a lógica em “pacotes” (um que representa a interface com o usuário – visão, um que conterá o domínio da aplicação – modelo, e um que terá as classes responsáveis por controlar o fluxo da aplicação – controlador) e fazer com que as informações sigam um caminho certo.

Após essa pequena introdução teórica vamos ver como o Spring implementa esse padrão:

Figura 1 – Fluxo de informações no Spring Web MVC

1 – A requisição do usuário sempre chega em um único servlet, o Dispatcher Servlet. Esse é um padrão muito comum em frameworks MVC chamado front controller (controlador frontal) onde um único servlet é responsável por receber a requisição, delegar o processamento para os outros componentes da aplicação e devolver uma resposta para o usuário;
2 – Uma vez que o Dispatcher Servlet tem a requisição ele precisa descobrir para qual controller essa requisição será enviada. Para isso ele pede ajuda para o Handler Mapping. Baseado na URL da requisição ele indica qual é o controlador a ser invocado;
3 – A requisição é então enviada para o controlador que cuidará dos dados contidos nela. Uma vez que o controlador recebe a requisição ele processa os dados que ela trouxe e executa alguma regra do negócio da aplicação (faz uma venda, adiciona um novo produto no estoque, aluga um dvd, abre uma os, …);
4 – Frequentemente a lógica processada pelo controlador resulta em alguma informação que deve ser levada de volta para o usuário (o model). Somente enviar a informação de volta não é o suficiente, ela deve ser formatada de um jeito que o usuário a entenda, para isso ela deve ser enviada para a view. Para isso o model e alguns dados da view são encapsulados em um objeto ModelAndView e retornados ao Dispatcher;
5 – Como o controlador não fica preso a apenas uma view ele envia uma dica no objeto ModelAndView para o Dispatcher saber para qual view deve enviar os dados. O Dispatcher repassa essa dica para o ViewResolver que devolve qual view deve ser chamada;
6 – Por fim o Dispatcher envia as informações (model) para a view (página JSP) que acabou de descobrir. A página renderiza as informações recebidas e é devolvida ao usuário.

Simples de entender, não!?

Vamos por a mão na massa então! A IDE será o NetBeans 6.9.1. Crie uma nova Aplicação Web (Java Web > Aplicação Web) e no último passo do assistente selecione o framework Spring Web MVC (Figura 2) e finalize.

Figura 2 – Incluir o framework Spring Web MVC no projeto

O NetBeans já cria alguns arquivos para nós (legal ele né). Vamos dar uma analisada nos códigos que ele gerou.

Figura 3 – Arquivos gerados pelo NetBeans

O arquivo de configuração do Dispatcher Servlet é o dispatcher-servlet.xml, nele são declarados todos os beans que o servlet precisa para conhecer os controladores e os outros componentes que o auxiliam no decorrer da aplicação.

Repare que o arquivo redirect.jsp é o único arquivo que fica fora do diretório WEB-INF. Isso é feito porque uma boa prática é que todas as views fiquem dentro do diretório WEB-INF para que só possam ser acessadas a partir do Dispatcher. O redirect.jsp apenas envia qualquer requisição feita na raiz da aplicação para a página index.jsp que está dentro do WEB-INF.

Para poder fazer esse redirecionamento é necessário que o fluxo explicado logo antes (6 passos) seja seguido. Para tal o NetBeans criou os seguintes beans no arquivo de configuração do Dispatcher:

 name="indexController"
	class="org.springframework.web.servlet.mvc.ParameterizableViewController"
	p:viewName="index" />

O controlador que será responsável por uma requisição à página index.jsp. Como esse controlador não vai fazer nenhum processamento dos dados da requisição foi criado um controlador da classe ParameterizableViewController que o Spring Web MVC já tem implementado. O que ele faz é apenas repassar um ModelAndView informando o nome da view (informado no parâmetro viewName) para o Dispatcher.

 id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
	 name="mappings">
		>
			 key="index.htm">indexController>
		>
	>
>

Quando é utilizado o ParameterizableViewController é necessário mapear quais URLs serão direcionadas para aquele controlador, por isso foi criado o bean urlMapping da classe SimpleUrlHandlerMapping que apenas linka a url “index.htm” ao controlador indexController.

 id="viewResolver"
	class="org.springframework.web.servlet.view.InternalResourceViewResolver"
	p:prefix="/WEB-INF/jsp/"
	p:suffix=".jsp" />

O viewResolver é quem vai ajudar o Dispatcher a saber para qual view encaminhar o ModelAndView que o controlador retornar (passo 5 do fluxo ali em cima). Como no ModelAndView só vai ter o nome lógico da view (no caso da index vai ter apenas a String index que foi definida no controlador indexController), o que o viewResolver faz é criar o caminho da view utilizando o prefixo e sufixo informados na declaração do bean. Para descobrir o caminho da view index ele vai fazer:

“WEB-INF/jsp/” + “index” + “.jsp” => resultando em “WEB-INF/jsp/index.jsp”

E por fim o NetBeans criou um bean sem id:

 class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/>

Esse bean é o cara que vai analisar todas as outras URLs e mapeá-las para os nossos controladores. Isso vai ficar mais claro daqui a pouquinho quando fizermos o nosso controlador.

Bom, vamos a nossa aplicação então, vou utilizar a idéia de uma aplicação que tem no livro Use a Cabeça: Servlets & JSP: uma aplicação que dá conselhos sobre cerveja! O usuário diz o tipo da cerveja que ele quer e nossa aplicação retorna alguns conselhos sobre quais cervejas ele poderia tomar.

Vamos aproveitar a estrutura que o NetBeans já criou e apenas alterar a página index.jsp para ser o nosso formulário onde o usuário vai indicar qual tipo de cerveja ele quer tomar:

<%@page contentType="text/html" pageEncoding="UTF-8"%>

 

    
        
        Cervejeiro Online
    
 
    
        Eu sou um cervejeiro profissional!
        
        
            Qual tipo de cerveja você prefere?

Quando o usuário pedir o conselho da nossa aplicação sobre cervejas do tipo que ele selecionou os dados serão enviados via POST para a URL sugestor.htm.

Lembra daquele bean que o NetBeans criou sem id (ControllerClassNameHandlerMapping)? Então, ele vai entrar em ação agora! Ele vai ser chamado pelo Dispatcher para identificar qual controlador vai receber a requisição.

O processo que esse bean utiliza para identificar qual controlador vai ser chamado é apenas pegar a String existente na URL até “.htm” e concatenar com “Controller”. Nesse caso o controlador que vai ser chamado é o SugestorController. Caso nosso formulário enviasse os dados para cervejeiro.htm o controlador que o Dispatcher tentaria invocar seria o CervejeiroController. Facinho não? ^^

Sendo assim vamos construir o nosso controlador:

public class SugestorController extends AbstractController {
 
    private SugestorService sugestor;
 
    public void setSugestor(SugestorService sugestor) {
        this.sugestor = sugestor;
    }
 
    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {
 
        String tipo = request.getParameter("tipo");
 
        List<cerveja> sugestoes = sugestor.sugerir(tipo);
 
        ModelAndView modelAndView = new ModelAndView("sugestao", "cervejas", sugestoes);
 
        return modelAndView;
    }
}

Uma coisa que não podemos esquecer: para o Spring entender que essa nossa classe é um controlador ela deve herdar de AbstractController ou qualquer outra classe que represente um controlador para o Spring Web MVC (pode ver mais exemplos aqui na referência oficial).

Uma boa prática no desenvolvimento de aplicativos MVC é nunca deixar toda a lógica dentro do controlador, usar ele apenas para delegar funções para outros componentes para que esses sim executem a lógica.

Para isso servem os famosos Services! Nosso controlador recebe um SugestorService (injetado pelo Spring) e delega para ele a função de sugerir as cervejas para o usuário.

Depois que o SugestorService retorna uma lista de cervejas (já já veremos a classe Cerveja que faz parte do model da nossa aplicação) para o controlador é hora de montar o ModelAndView que deve ser retornado para o Dispatcher.

Nosso ModelAndView foi instanciado com 3 parâmetros sendo o primeiro o nome da view (aquela dica que o bean viewResolver vai usar para montar o nome do arquivo lembra?), o segundo é o nome que a lista de cervejas terá na página JSP e o terceiro é a lista propriamente dita, quer dizer, quando formos mostrar as cervejas na página WEB-INF/jsp/sugestao.jsp (eu sei que você lembra como o viewResolver acha o arquivo da view, só escrevi ele ali pra você não esquecer mesmo.. hehehe) a lista terá o nome cervejas.

Figura 4 – Fluxo de componentes que são executados para uma requisição (sem contar com a view)

Com isso nosso controlador ficou muito bem projetado, recebe uma requisição, chama um Service para realizar a lógica de negócio da aplicação e devolve um ModelAndView para o Dispatcher. Exatamente o que se espera de um controlador: que ele controle os componentes necessários para a regra de negócio ser executada.

Vamos ver como o SugestorService funciona. Apenas um pequeno detalhe: SugestorService é uma interface que apenas diz que o Service que a implementar deve sugerir uma lista de cervejas a partir do tipo (é bom utilizar as interfaces! se você não tem esse costume passe a ter! Lendo os primeiros posts dessa série você vai entender porquê):

public interface SugestorService {
    List<cerveja> sugerir(String tipo);
}

Agora vejamos como esse Service funciona mesmo através do SugestorServiceImpl:

public class SugestorServiceImpl implements SugestorService {
 
    public List<cerveja> sugerir(String tipo) {
        List<cerveja> cervejasSugeridas = new ArrayList<cerveja>();
 
        if (tipo.equals("pilsen")){
            cervejasSugeridas.add(criarCerveja("Skol", 600));
            cervejasSugeridas.add(criarCerveja("Antartica", 600));
        } else if (tipo.equals("chop")){
            cervejasSugeridas.add(criarCerveja("Brahma", 600));
        } else if (tipo.equals("malzbier")){
            cervejasSugeridas.add(criarCerveja("Brahma Malzbier", 355));
            cervejasSugeridas.add(criarCerveja("Caracu", 355));
        }
 
        return cervejasSugeridas;
    }
 
    private Cerveja criarCerveja(String nome, Integer quantidade) {
        Cerveja cerveja = new Cerveja();
        cerveja.setNome(nome);
        cerveja.setQuantidade(quantidade);
        return cerveja;
    }
}

Apenas verificamos qual o tipo que o usuário selecionou e montamos uma lista de cervejas a partir dele (desculpe se não gosta das que coloquei, juro que tentei ser bem simples e eclético).

A classe que representa nosso modelo é um simples POJO com o nome e a quantidade (em mls) da cerveja:

public class Cerveja {
    private String nome;
    private Integer quantidade;
 
    public String getNome() {
        return nome;
    }
 
    public void setNome(String nome) {
        this.nome = nome;
    }
 
    public Integer getQuantidade() {
        return quantidade;
    }
 
    public void setQuantidade(Integer quantidade) {
        this.quantidade = quantidade;
    }
}

Bom, com toda a regra de negócio implementada vamos para a página que vai mostrar as cervejas sugeridas pela nossa aplicação (sugestao.jsp):

<%@ page contentType="text/html" pageEncoding="UTF-8"%> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> Minha Sugestão

Eu acho que você deveria experimentar:

- ml

Voltar

Apenas percorremos a lista de cervejas exibindo-as na tela (lembrando que o nome da lista é cervejas pois foi esse o nome que foi passado no ModelAndView lá no Controller).

Para fazermos nossa aplicação rodar precisamos apenas declarar o SugestorController e o SugestorServiceImpl no arquivo de configuração do Dispatcher Servlet:

 id="sugestorService" class="br.javasimples.cervejeiro.service.impl.SugestorServiceImpl" />
 name="sugestorController"
	class="br.javasimples.cervejeiro.controller.SugestorController">
	 name="sugestor" ref="sugestorService" />
>

Prontinho!! Simples códigos não? Só com essas pequenas classes nós construímos um Sugestor de Cervejas MVC!!!

Figura 5 – Escolhendo um tipo e pedindo a opinião da aplicação

Figura 6 – Cerveja sugerida pela aplicação

Espero que com esse pequeno tutorial e essa pequena aplicação você tenha entendido (pelo menos um pouco) o padrão MVC e como ele torna nossa aplicação muito bem estruturada. Dê uma olhada como os pacotes do meu projeto ficaram bem separados:

Figura 7 – Hierarquia de pastas e pacotes da aplicação

Caso queira pegar o projeto fique a vontade para baixá-lo por aqui.

Apenas um último conselho antes de encerrarmos este post: o que foi apresentado aqui foi a estrutura mais básica possível do Spring Web MVC, apenas com o que vimos você consegue fazer uma aplicação de pequeno porte porém eu aconselho fortemente você procurar aprender mais sobre o framework antes de utilizá-lo no desenvolvimento do seu projeto de graduação (hehehe).

O Spring Web MVC contém muitos (muitos mesmo!) outros beans que facilitam muito a vida do desenvolvedor! Vale mesmo a pena dar uma procurada por fontes mais avançadas. Um livro bem didático é o Spring in Action 2 (Craig Walls, 2008) e a referência é incrível!

Até a próxima!

[]s,
Saab.

Spring Security 3 -> Deixando sua aplicação Web segura!

Felipe Saab — Tue, 19 Oct 2010 15:46:00 +0000

Continuando com o assunto dos posts anteriores, vamos falar sobre mais uma vantagem do Spring Framework: o Spring Security.

O Spring Security antes era conhecido como Acegi Security pois era um projeto paralelo ao Spring Framework e aos poucos foi integrado a ele. Quando eu digo ‘integrado’ eu quero dizer que ele (Acegi Security) continuou sendo desenvolvido baseado no Spring, ou seja, ele funciona perfeitamente sobre o container do Spring. Há algum tempo o nome do projeto foi alterado para Spring Security pois ele acabou entrando para a família do Spring (péssimo trocadilho não… ).

Mesmo com a integração, quando você baixa o Spring Framework o Spring Security não está incluído. Precisamos baixá-lo separadamente.

O Spring Security utiliza uma biblioteca externa para logging das suas funções e essa biblioteca também não vem no download do projeto, portanto temos que baixar o Apache Commons Logging também.

Apenas mais um detalhe: se você acompanhou os posts anteriores sobre o Spring Framework você notou que a versão do framework era a 2.5 (que vem nativamente com o NetBeans 6.8), porém neste post eu já irei utilizar a mais nova versão: 3.0 pois o Spring Security 3.0 (versão melhor e mais fácil de usar do que a anterior) só roda em cima do Spring Framework 3.0.

Ahh, vou trocar a IDE também, ao invés de utilizar o NetBeans eu irei utilizar o SpringSource Tool Suite (Eclipse que o pessoal da SpringSource deu uma turbinada para facilitar a vida de quem usa o Spring).

Seguem os links para os downloads necessários:

Nosso escopo para a aplicação: teremos dois tipos de usuários na aplicação: Funcionários e Gerentes. Os funcionários tem acesso apenas à área restrita a funcionários e os gerentes tem acesso tanto à área de funcionários (mesmo sendo gerentes eles também são funcionários poxa) quanto à área restrita aos gerentes.

A autenticação será baseada nos dados contidos em uma tabela no banco de dados, então para o usuário possuir acesso ele deve estar cadastrado no banco de dados.

OBS: Também será necessário fazer o download do driver JDBC para a conexão com o banco de dados que você for utilizar. Eu irei utilizar o MySQL, caso você também use ele pode pegar o driver aqui.

Nossa tabela que conterá os dados dos usuários será essa:

CREATE TABLE `users` (
  `username` VARCHAR(15) COLLATE utf8_unicode_ci NOT NULL,
  `password` VARCHAR(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  `authority` VARCHAR(30) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY  (`username`)
)

Os campos só estão em inglês porque eu fiquei com preguiça de mudar para português, desculpem..

Com o banco de dados pronto nós já podemos por a mão na massa!

Criei um novo projeto (Dynamic Web Project) no STS (SpringSource Tool Suite) chamado ControleAcesso e a primeira coisa que fiz foi incluir as dependências no classpath, ou seja, todos os .jar encontrados na pasta /dist dos releases do Spring Framework e do Spring Security e também o .jar do Apache Commons Logging e o .jar o driver JDBC do MySQL:

OBS: Adicionei também os .jar referentes a JSTL para poder utilizá-la nos JSPs.

Estrutura da Aplicação
Agora vou criar a estrutura básica de arquivos para a nossa aplicação:

Uma estrutura bem básica onde nós podemos ver que as páginas que estão na raiz da aplicação são as páginas de login, index e uma responsável por mostrar uma mensagem de acesso negado caso o usuário tente acessar uma página que não pode.

OBS: Essa é a estrutura final da aplicação, chegaremos até ela aos poucos durante o decorrer do post.

Depois existem mais duas pastas (funcionario e gerente) representando as partes da aplicação que somente usuários autenticados podem acessar. Nestas pastas eu coloquei apenas um index para confirmar que tivemos acesso ou não a página.

Vamos começar a ver as páginas então:

index.jsp (raíz):

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>


    
        
	Home Page
    
    
        Página de Boas Vindas
	Área de Funcionários
	

	Área de Gerentes

A página inicial da aplicação apenas dá as boas vindas ao usuário e mostra os possíveis caminhos para ele: área de funcionários ou área de gerentes.

funcionario/index.jsp

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>


    
        
	Área do Funcionário
    
    
        Bem Vindo a Área do Funcionário
	Retornar para a Página Inicial

gerente/index.jsp

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>


    
        
	Área do Gerente
    
    
        Bem Vindo a Área do Gerente
	Retornar para a Página Inicial

Pronto, esta é a estrutura básica da aplicação, caso você rode ela agora você vai conseguir navegar livremente pelas áreas que devem ser restritas (funcionários e gerentes).

Adicionando o Spring na aplicação
Próximo passo é por o Spring para funcionar nessa nossa aplicação. Como as bibliotecas já estão no classpath então vamos criar o arquivo de configuração do Spring: dentro da pasta WEB-INF crie um xml chamado “applicationContext“.

Caso esteja usando o STS basta clicar com o botão direito na pasta WEB-INF, ir em New e depois em Other. Vá na pasta Spring e selecione Spring Bean Configuration File, na proxima janela digite o nome (applicationContext) e na proxima janela você pode escolher os namespaces que quer usar no arquivo então deixe selecionado os seguintes: beans e sec. Quando selecionar o sec você ainda deve especificar o XSD do Spring Framework 3.0. Fazendo isso a IDE já vai criar a estrutura básica do arquivo de configuração com todos os namespaces.

O applicationContext.xml deve ficar parecido com este (já vou adiantar um detalhe e declarar o dataSource responsável por se comunicar com o banco de dados onde está a tabela com os usuários e suas autenticações):

 version="1.0" encoding="UTF-8"?>
 xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sec="http://www.springframework.org/schema/security"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">
 
    
     id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
         name="driverClassName" value="com.mysql.jdbc.Driver" />
	 name="url" value="jdbc:mysql://localhost/spring_security" />
	 name="username" value="root" />
	 name="password" value="123" />
    >
 
>

Para concluir esta etapa basta fazer uma pequena modificação no web.xml para adicionar um listener que o Spring tem para facilitar nossa vida. Sempre que a aplicação vai começar a funcionar esse listener procura pelo arquivo applicationContext.xml e carrega o Spring e os beans e configurações definidos nesse arquivo.

OBS: Tem como configurar o listener para receber uma lista com o nome de vários arquivos de configuração (caso você goste de separar as configurações em arquivos separados) e então ele carrega todos, porém esse é um assunto para outro post (ou uma rápida busca no google ).

Basta adicionar a seguinte tag no web.xml:

>
    >org.springframework.web.context.ContextLoaderListener>
>

OK, caso você execute a aplicação agora e ficar atento às mensagens de LOG você irá ver o Spring carregando e o dataSource sendo configurado, ou seja, tudo indo bem até aqui!

Aliás, verá também que você consegue facilmente acessar as áreas que deveriam ser restritas. Tudo certo até aqui.

Adicionando segurança na aplicação
Vamos começar a fazer algumas modificações para podermos adicionar a segurança na nossa aplicação.

Primeiro de tudo vamos adicionar um novo filtro no nosso web.xml. Esse filtro será responsável por interceptar todas as requisições à aplicacão, verificar se o usuário possui acesso e liberar a requisição normalmente ou então mostrar um erro.

Segue o XML necessário para a declaração e configuração do filtro:

    >
        >springSecurityFilterChain>
        >org.springframework.web.filter.DelegatingFilterProxy>
    >
 
    >
        >springSecurityFilterChain>
        >/*>
    >

A partir de agora todas as requisições serão interceptadas pelo Spring, só falta deixar bem claro para o Spring Security quem pode fazer o que na aplicação.

Antes de continuar com o processo de autenticação de usuários nós precisamos ter o usuários concorda? hehehe
Vou adicionar agora dois usuários para nossa aplicação: um gerente e um funcionário comum.

INSERT INTO users(username,password,authority) VALUES('func','func','ROLE_FUNC');
INSERT INTO users(username,password,authority) VALUES('ger','ger','ROLE_GER');

Agora já temos o usuário func e o usuário ger para poder testar na nossa aplicação.

Repare que o atributo authority foi preenchido com ROLE_FUNC e ROLE_GER. Isso ocorre porque o Spring Security sempre busca um prefixo no tipo de autorização de cada usuário e o padrão é este (“ROLE_”). Logo mais mostrarei como trocar para um prefixo a sua escolha como “FUNCAO_”, “AUTH_” ou o que você quiser.

Continuando: toda a autenticação será feita com a declaração de apenas dois beans no applicationContext.xml. Vamos ao primeiro:

 auto-config="true">
     login-page="/login.jsp" authentication-failure-url="/login.jsp?erro=invalido" />
     pattern="/funcionario/**" access="ROLE_FUNC,ROLE_GER" />
     pattern="/gerente/**" access="ROLE_GER" />
     pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
>

OBS: O prefixo das tags dos Spring Security é “sec” pois foi o namespace declarado para ele na tag root : xmlns:sec=”…”

A tag serve para definir os parâmetros básicos para o Spring Security saber o que fazer com as requisições. O atributo auto-config nos poupa de definir todas as tags necessárias para o funciomento correto, sendo assim, só precisamos nos focar no que realmente faz parte da nossa aplicação, como o que eu coloquei: formulário de login e URL’s que serão interceptadas.

Cada tag < intercept-url > identifica uma URL ou um padrão de URL’s e qual a permissão o usuário deve ter para acessar tal (tais) URL (s).
A primeira tag diz que todas as URL’s que comecem com “/funcionario/” só poderão ser acessadas por usuários que tiverem autorização ROLE_FUNC ou ROLE_GER.
Já a segunda restringe o acesso a todas URL’s que comecem com “/gerente/” para usuários que estiverem autorizados com ROLE_GER.
E a última tag define que qualquer outra URL que ainda não foi definida anteriormente pode ser acessada sem autenticação nenhuma.

Na tag < form-login> foram definidos alguns atributos meio básicos: login-page informando qual é a página de login e authentication-failure-url informando qual é a página que será exibida caso o login falhe (neste caso eu coloquei a mesma página de login e apenas enviei um parâmetro via GET para podermos saber quando ocorre o erro).

Segue a página de login e como deve ser o formulário:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

 

    
        
        Autenticação
    
    
        
            Usuário e/ou senha inválidos!


        
 
        
            Usuário: 

            Senha: 

            
        
        


        Retornar para a Página Inicial

Caso a página seja carregada com o parâmetro “erro” contendo o valor “invalido” então um erro será mostrado (fiz usando JSTL). E o formulário de login deve ser enviado para a URL “j_spring_security_check” passando como parâmetros o nome de usuário (j_username) e a senha (j_password). Esses nomes são padrões do Spring Framework e bem fáceis de serem seguidos.

O processo de login é simples assim e encerra as explicações sobre o primeiro bean responsável pela segurança de nossa aplicação.

Vamos ao próximo bean:

>
    >
         data-source-ref="dataSource"
            users-by-username-query="SELECT username, password, 'true' as enable FROM users WHERE username=?"
            authorities-by-username-query="SELECT username, authority FROM users WHERE username=?" />
    >
>

Dentro do < authentication-manager > é onde especificamos onde o Spring Security deve buscar os dados para verificar se um usuário está autenticado ou não. Como já tinhamos previsto desde o começo do post que iríamos fazer a autenticação através do banco de dados, utilizamos a tag < jdbc-user-service-data-source > passando o dataSource que conecta no banco que contém nossos usuários.

Quando o Spring Security tenta autenticar um usuário com dados vindos de um banco de dados ele possui um padrão: para cada usuário devem ser retornados 3 campos: username, password e enable, sendo eles usuário, senha e o último dizendo se o usuário está habilitado ou não.

Para não ficarmos presos no padrão de tabelas que o Spring Security sugere para usuários, nós podemos escrever quais querys ele irá utilizar para recuperar os dados que ele precisa.

O atributo users-by-username-query deve trazer os dados do usuário (username, password e enabled) selecionado pelo nome de usuário e o atributo authorities-by-username-query deve trazer o nome de usuário e o tipo de autenticação (username, authority) também selecionado pelo nome de usuário.

Com essa flexibilidade de configuração é possível utilizar qualquer estrutura de tabelas responsável por armazenar os usuários.

E pronto! Agora nossa aplicação web já possui um mecanismo de segurança para restringir o acesso apenas a usuários autenticados! Executando a aplicação agora você verá que só consegue acessar a área de funcionários autenticando-se como um funcionário ou gerente, exatamente como havíamos configurado.

Mudar o prefixo do tipo de autorização
Para mudar o prefixo padrão (ROLE_) podemos setar o atributo role-prefix da tag < jdbc-user-service-data-source >.

>
    >
         data-source-ref="dataSource"  role-prefix="TIPO_"
            users-by-username-query="SELECT username, password, 'true' as enable FROM users WHERE username=?"
            authorities-by-username-query="SELECT username, authority FROM users WHERE username=?" />
    >
>

Com essa configuração os prefixos devem ser “TIPO_”. Ex de tipos de autorização: TIPO_GERENTE e TIPO_FUNCIONARIO.

Logout
Para o usuário efetuar logout no sistema basta acessar a URL “j_spring_security_logout” na raiz da aplicação.

Ex: para colocar um link “Sair” na página /funcionario/index.jsp devemos colocar assim:

Sair.

Porque a url deve ser acessada na raiz da aplicação web: /Aplicacao/j_spring_security_logout e não /Aplicacao/funcionario/j_spring_security_logout.

Acesso Negado
Caso o usuário logado como funcionário queira acessar a seção restrita a gerentes ele irá receber uma página de erro bem estranha (que o servidor de aplicativos gera). Para mostrar uma página mais amigável avisando que o usuário não tem acesso a uma certa área basta preencher o atributo access-denied-page da tag < http >.

 auto-config="true" access-denied-page="/negado.jsp">
     login-page="/login.jsp" authentication-failure-url="/login.jsp?erro=invalido" />
     pattern="/funcionario/**" access="ROLE_FUNC,ROLE_GER" />
     pattern="/gerente/**" access="ROLE_GER" />
     pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
>

negado.jsp:


    
        
        Acesso Negado
    
    
        Acesso Negado
        Página Inicial

Encriptação da senha
Caso queira que a senha seja protegida por algum algoritmo de encriptação basta adicionar uma nova tag no authentication-manager:

>
    >
         hash="md5"/>
         data-source-ref="dataSource"  role-prefix="TIPO_"
            users-by-username-query="SELECT username, password, 'true' as enable FROM users WHERE username=?"
            authorities-by-username-query="SELECT username, authority FROM users WHERE username=?" />
    >
>

Neste caso o algoritmo usado é o MD5, poderia ser o MD4, SHA, entre outros.

Para inserir o usuário com uma senha criptografada com MD5 no MySQL fica assim:

INSERT INTO users(username,password,authority) VALUES('func',MD5('func'),'ROLE_FUNC');

Exibindo partes da página apenas para usuários autorizados UPDATE(19/03/2011)

Respondendo a pergunta que nosso leitor Gerson postou nos comentários vamos ver como podemos restringir partes da página com base na autorização que o usuário possui.

A primeira coisa a fazer é ter certeza de que a biblioteca spring-security-taglibs-3.x.x.jar está no classpath da aplicação.

Depois temos que importar as taglibs do Spring Security na página onde queremos usá-la e então utilizá-las de fato. Referência das taglibs do Spring Security.

Eu alterei a página /funcionario/index.jsp para mostrar uma mensagem de boas vindas somente para os usuários que possuem a autorização ROLE_GER:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>


    
        
        Área do Funcionário
    
    
        Bem Vindo a Área do Funcionário
 
        
            Bem vindo gerente .
        
 
        


        Sair.

        Retornar para a Página Inicial

Fácil de ler e de fazer não é?
Só para explicar melhor, o que utilizamos foram as tags authorize e authentication.

authorize: tudo o que estiver dentro esta tag só irá ser rendererizado caso a autorização do usuário logado atenda a regra de algum atributo que informarmos. Neste exemplo usei o atributo ifAnyGranted, quer dizer que o conteúdo da tag só irá ser renderizado caso o usuário logado possua alguma das autorizações (ROLEs) informadas no atributo.

Para informar mais de uma autorização basta separá-las por vírgula.
Ex: ifAnyGranted=”ROLE_GER,ROLE_FUNC”.
Neste caso o conteúdo da tag será renderizado caso o usuário possua autorização ROLE_GER ou ROLE_FUNC.

Outros possíveis atributos são: ifAllGranted (somente irá renderizar caso o usuário possua todas as autorizações informadas) e ifNotGranted (irá renderizar somente se o usuário não possuir a autorização informada).

authentication: utilizada para recuperar o objeto Authentication que está guardado no contexto do Spring Security. O usuário logado é guardado na propriedade principal do objeto Authentication, sendo assim nós podemos exibir seu nome de usuário através do atributo property informando principal.username.

Obs: os dados do usuário logado são guardados em um objeto que implementa a interface UserDetails, ou seja, o atributo principal do objeto Authentication é uma implementação de UserDetails.

E chegamos ao final de mais um post.
O projeto do STS está disponível para download aqui.

A seção de comentários está aberta para feedback e dúvidas pessoal, fiquem a vontade. =]

Até a proxima,
Saab.

Spring Framework Parte 4 -> Integração com o Hibernate

Felipe Saab — Wed, 22 Sep 2010 22:22:36 +0000

Antes de começarmos mais um post da série de tutoriais sobre o Spring Framework eu sugiro a leitura dos posts anteirores (caso você ainda não tenha conhecimento dos assuntos abordados):

Assumindo então que agora você já sabe sobre o Spring, vamos ver como ele facilita o uso do framework de mapeamento objeto-relacional Hibernate (versão 3.x).

OBS: Irei comentar detalhadamente apenas coisas relacionadas ao Spring, ou seja, espero que você já possua o conhecimento necessário do Hibernate.

Apenas para lembrarmos como o Spring tenta padronizar o acesso a dados em uma base de dados vamos dar uma olhada na imagem do post anterior (retirada do livro Spring in Action 2, Manning 2008):

Interpretando a figura a gente consegue chegar em algo assim: o nosso objeto responsável pelas operações de manipulação de dados irá utilizar um template (fornecido pelo Spring) que saiba interagir com o Hibernate (que conste no classpath e cuja versão seja 3.x) e que irá utilizar um DAO que saiba se comunicar com a base de dados (um data source).

Só com o parágrafo acima já deu pra ver que precisaremos criar e configurar alguns beans no Spring: um data source que se comunique com a base de dados e um template que se comunique com o Hibernate.

Vamos a eles então:

     id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
         name="driverClassName" value="com.mysql.jdbc.Driver" />
         name="url" value="jdbc:mysql://localhost/hibernate_teste" />
         name="username" value="root" />
         name="password" value="123" />
    >
 
     id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
         name="sessionFactory" ref="sessionFactory" />
    >

Como você pode notar o template precisa de uma referência para um bean que seja uma implementação de org.hibernate.SessionFactory e aí depende de como você está acostumado a mapear os objetos para tabelas: utilizando XML ou Anotações.

Utilizando XML:

     id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
         name="dataSource" ref="dataSource" />
         name="mappingResources">
            >
                >Livro.hbm.xml>
            >
        >
         name="hibernateProperties">
            >
                 key="hibernate.dialect">org.hibernate.dialect.MySQLDialect>
                 key="hibernate.show_sql">true>
            >
        >
    >

Utilizando classes anotadas:

     id="sessionFactory"
          class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
         name="dataSource" ref="dataSource" />
         name="annotatedClasses">
            >
                >spring_hibernate.modelo.Livro>
            >
        >
         name="hibernateProperties">
            >
                 key="hibernate.dialect">org.hibernate.dialect.MySQLDialect>
                 key="hibernate.show_sql">true>
            >
        >
    >

Os beans são bem parecidos, precisam de pelo menos três propriedades setadas via injeção de dependência:

– dataSource -> referência para o data source
– hibernateProperties -> uma lista (do tipo props, onde tanto a chave (key) quanto o valor são Strings) contendo as propriedades da session factory que queremos setar

E a terceira propriedade depende do bean que está sendo declarado:

– se for LocalSessionFactoryBean utiliza-se a propriedade mappingResources que recebe uma lista contendo todos os XMLs responsáveis pelo mapeamento
– se for AnnotationSessionFactoryBean utiliza-se a propriedade annotatedClasses que recebe uma lista contendo todas as classes que representam o mapeamento

OK. Estes são os beans que o Spring fornece para facilitar a nossa vida ao utilizar o Hibernate. Vamos então a um pouco de código para demonstrar como nós utilizamos tais beans nas nossas próprias classes.

Primeiro de tudo, no banco de dados vamos criar uma tabela para os testes:

CREATE TABLE  `Livros` (
    `liv_cod` INT NOT NULL ,
    `liv_titulo` VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL ,
    PRIMARY KEY (  `liv_cod` )
) ENGINE = INNODB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Nossa tabela então será sobre livros, contendo apenas o código e o título do livro, vamos a classe que vai representar um livro:

public class Livro {
 
    private int cod;
    private String titulo;
 
    public Livro() {
    }
 
    public int getCod() {
        return cod;
    }
 
    public void setCod(int cod) {
        this.cod = cod;
    }
 
    public String getTitulo() {
        return titulo;
    }
 
    public void setTitulo(String titulo) {
        this.titulo = titulo;
    }
}

Um simples POJO para representar o livro…

Neste tutorial eu irei fazer o mapeamento utilizando um XML, vamos a ele:

 version="1.0" encoding="UTF-8"?>

>
   name="spring_hibernate.modelo.Livro" table="Livros">
     name="cod" column="liv_cod" type="int">
       class="increment"/>
    >
     name="titulo" column="liv_titulo" />
  >
>

Como a tabela contém apenas dois campos o mapeamento fica bem simples: a chave primária que é a variável de instância cod (coluna liv_cod) e a variável de instância titulo ligada a coluna “liv_titulo”.

Só chamando a atenção para o generator do cod, que é increment, ou seja, não precisamos setar o código de um novo livro para adicioná-lo ao banco, o novo código será gerado sozinho pelo Hibernate.

Muito bem, agora que o mapeamento da classe Livro para a tabela Livros está feito vamos começar a escrever o nosso DAO. Primeiro vamos a interface (gosto de reforçar a idéia de que interfaces devem ser utilizadas):

public interface IBanco {
 
    public Livro InserirLivro(Livro livro);
 
    public void AtualizarLivro(Livro livro);
 
    public void ApagarLivro(Livro livro);
 
    public List<livro> SelecionarLivrosPorTitulo(String titulo);
 
    public Livro SelecionarLivroPorCodigo(int cod);
}

Acho que o único comentário que essa interface merece é no método InserirLivro porque ele recebe o Livro que será inserido e retorna outro Livro. Isso se deve ao fato da variável de instância cod do Livro ser nula quando o livro estiver sendo gravado no banco e após a sua gravação o Hibernate retorna qual valor foi atribuído como código, ou seja, depois de gravado no banco é que nós descobrimos o valor do código, então apenas atualizamos o objeto Livro com o seu novo código e retornamos um objeto consistente.

Vamos à implementação dessa interface para podermos ver como o template do Hibernate facilita a nossa vida:

public class BancoDados implements IBanco {
 
    HibernateTemplate hibernateTemplate;
 
    public void setHibernateTemplate(HibernateTemplate hibernateTemplate) {
        this.hibernateTemplate = hibernateTemplate;
    }
 
    public Livro InserirLivro(Livro livro) {
        int cod = (Integer) hibernateTemplate.save(livro);
        livro.setCod(cod);
        return livro;
    }
 
    public void AtualizarLivro(Livro livro) {
        hibernateTemplate.update(livro);
    }
 
    public void ApagarLivro(Livro livro) {
        hibernateTemplate.delete(livro);
    }
 
    public List<livro> SelecionarLivrosPorTitulo(String titulo) {
        //utilizando criteria
        DetachedCriteria crit = DetachedCriteria.forClass(Livro.class)
                .add(Restrictions.like("titulo", titulo));
        return hibernateTemplate.findByCriteria(crit);
 
        //utilizando HQL
        //String hql = "from Livro where titulo like '%"+titulo+"%'";
        //return hibernateTemplate.find(hql);
    }
 
    public Livro SelecionarLivroPorCodigo(int cod) {
        Livro livro = (Livro) hibernateTemplate.get(Livro.class, cod);
        return livro;
    }
}

Hibernate já facilita a vida do desenvolvedor, adicionando o Spring na brincadeira então, tudo fica mais fácil como você acabou de ver.

Creio que os métodos save, update e delete do template são completamente auto explicativos.

Porém quando o assunto vai para o lado da busca e seleção de registros, temos alguns métodos que podem ajudar:

– método get que busca um objeto da classe passada por parâmetro que contenha a chave primária igual ao segundo parâmetro
– método find que realiza uma busca de acordo com uma query HQL
– método findByCriteria para quem está mais acostumado a fazer busca com criterias

Os métodos find e findByCriteria (e os outros find… que o template tem disponível) retornam um List tipado com objetos relacionados à consulta, no nosso caso então é retornado um List .

Mais um pequeno detalhe: o HibernateTemplate que usamos nesta classe deverá ser injetado pelo container, ou seja, essa classe será mais um bean para o Spring gerenciar. O arquivo de configuração completo deste tutorial será assim:

 version="1.0" encoding="UTF-8"?>
 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-2.0.xsd">
 
     id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
         name="driverClassName" value="com.mysql.jdbc.Driver" />
         name="url" value="jdbc:mysql://localhost/hibernate_teste" />
         name="username" value="root" />
         name="password" value="123" />
    >
 
     id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
         name="dataSource" ref="dataSource" />
         name="mappingResources">
            >
                >Livro.hbm.xml>
            >
        >
         name="hibernateProperties">
            >
                 key="hibernate.dialect">org.hibernate.dialect.MySQLDialect>
                 key="hibernate.show_sql">true>
            >
        >
    >
 
     id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
         name="sessionFactory" ref="sessionFactory" />
    >
 
     id="banco_dados" class="spring_hibernate.BancoDados">
         name="hibernateTemplate" ref="hibernateTemplate" />
    >
 
>

Como exemplo final eu só gostaria de deixar um código de como utilizar essa classe BancoDados:

public class Main {
 
    public static void main(String[] args) {
 
        ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/spring.xml");
        System.out.println("Spring inicializado");
 
        BancoDados banco = (BancoDados) ctx.getBean("banco_dados");
 
        Livro livro1 = new Livro();
        livro1.setTitulo("Spring + Hibernate");
        Livro livro2 = new Livro();
        livro2.setTitulo("Hibernate Avançado");
        System.out.println("Objetos Livro inicializados");
 
        livro1 = banco.InserirLivro(livro1);
        livro2 = banco.InserirLivro(livro2);
        System.out.println("Livros gravados no banco");
 
        //zerando os objetos Livro
        livro1 = null;
        livro2 = null;
 
 
        System.out.println("Selecionando livros por código");
        livro1 = banco.SelecionarLivroPorCodigo(1);
        exibe(livro1);
 
        livro2 = banco.SelecionarLivroPorCodigo(2);
        exibe(livro2);
 
        System.out.println("Selecionando livros que contenham 'Hibernate' no título");
        List<livro> lista = banco.SelecionarLivrosPorTitulo("Hibernate");
        for (Livro l : lista){
            exibe(l);
        }
 
        System.out.println("Atualizando livro");
        livro1.setTitulo(livro1.getTitulo()+" Segunda Edição");
        banco.AtualizarLivro(livro1);
 
        System.out.println("Apagando livro");
        banco.ApagarLivro(livro2);
    }
 
    static void exibe(Livro livro) {
        if (livro == null)
            System.out.println("Livro não encontrado");
        else
            System.out.println("Livro -> cod: " + livro.getCod() + " | Título: " + livro.getTitulo());
    }
}

Muito bem leitor, se você chegou até aqui você vai desenvolver com uma produtividade bem alta porque agora que você já sabe Hibernate E Spring você pode se concentrar muito mais na camada de negócios, ou seja, não precisa perder muito tempo codificando acesso a banco de dados e operações necessárias para manipulação dos dados.

Caso você queira os arquivos que eu desenvolvi neste tutorial basta pegá-los aqui (o arquivo está meio pesado por causa das bibliotecas).

Dúvidas, críticas e etc fique a vontade para usar os comentários..

Até a próxima,
Saab.

Spring Framework Parte 3 -> Java Database Connectivity (JDBC)

Felipe Saab — Thu, 02 Sep 2010 12:50:56 +0000

Bem vindo leitor a mais um post da série Spring Framework.

Caso você ainda não leu os posts anteriores, por favor dê um pulinho bem rápido neles:

Vamos ao nosso próximo assunto então: JDBC e como o Spring facilita esse cara pra gente!

Tirando essa imagem do livro Spring in Action 2 (Manning, 2008) nós já conseguimos ver bem por cima como que o Spring pretende acessar de maneira padronizada a base de dados (Hitting the database) através de um objeto de acesso aos dados (DAO), um template (provido pelo próprio Spring) e caso nós quiséssemos, o Spring também oferece suporte padrão para alguns frameworks de persistência (será um dos próximos artigos desta série).

Tudo muito legal, muito bonito! Vamos tentar seguir este modelinho porque ele é bem bonitinho e vai nos ajudar um pouco. Apenas avisando que o jeito que descreverei neste tutorial não é o único jeito de acessar os dados através do seu driver JDBC, porém é um jeito que eu achei bem interessante e que vale a pena todos sabermos um pouquinho… =]

Existem apenas 2 conceitos básicos que o Spring nos sugere para o acesso rápido e fácil aos dados através de drivers JDBC: DataSource (DAO fornecido pelo Spring) e JdbcTemplate (template para acesso a dados através de um driver JDBC fornecido pelo Spring):

DataSource é uma classe provida pelo nosso querido Spring Framework e que se preocupa com toda a conexão e conversação com o driver JDBC que iremos utilizar (neste exemplo iremos utilizar o driver JDBC para o banco de dados MySQL). Em palavras um pouco mais técnicas, esta classe irá se resonsabilizar por nos entregar um objeto java.sql.Connection, java.sql.Statement, entre esses objetos que utilizamos quando o assunto é conexão de dados JDBC.

JdbcTemplate é uma outra classe muito útil provida pelo nosso ~~adorado~~ Spring! Este template provê métodos padronizados para acessarmos os dados (selecioná-los e manipulá-los), ou seja, fazer tudo o que podemos fazer com eles de um jeito bem fácil de acessar (como você irá descobrir logo a frente).

Muito bem, com esses dois conceitos já pintados na sua cabeça, por favor responda corretamente a próxima pergunta: “Já que estas classes são providas pelo nosso amigo Spring, quem instancia elas?”. Exato!! O próprio Spring cria os beans para estas classes, tudo o que temos que fazer é declarar estes beans no arquivo de configuração do Spring. Vamos a ele então:

 version="1.0" encoding="UTF-8"?>
 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-2.0.xsd">
 
     id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
         name="driverClassName" value="com.mysql.jdbc.Driver" />
         name="url" value="jdbc:mysql://localhost/spring_jdbc" />
         name="username" value="root" />
         name="password" value="123" />
    >
 
     id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
         name="dataSource" ref="dataSource" />
    >
 
>

Tão simples quanto encher um copo com água! Eu sinto até orgulho de mostrar como é fácil conectar com uma fonte de dados JDBC através do Spring!

O nosso primeiro bean é o dataSource. Como eu já disse ali em cima, esse é o cara responsável por conversar com o driver JDBC. Então nada mais justo que a gente ensinar ele a se comunicar com o driver passando os parâmetros corretos não é… Os parâmetros (injetados através da DI) passados para o dataSource foram: dataClassName (qual driver JDBC será usado), url (caminho do JDBC para se conectar até o banco de dados desejado), username (login do banco de dados) e password (senha do banco de dados).

No caso desse nosso exemplo, o driver JDBC é do MySQL, nunca esqueça que o driver deve estar no classpath em!!! Segue uma foto te ensinando como adicionar o driver JDBC do MySQL no NetBeans:

E o segundo bean do arquivo de configuração é o jdbcTemplate que é o template provido pelo Spring para facilitar a manipulação dos dados. A unica dependência que este bean tem é o próprio dataSource, ou seja, ele precisa de uma referência para um dataSource para saber em qual banco ele vai executar os comandos que quisermos. Sendo assim, de um jeito muito fácil (injeção de dependência), nós passamos uma referência do nosso dataSource já criado para ele. ^^

Só fazendo uma pequena pausa no Spring agora, vamos falar um pouquinho do banco de dados: criei uma tabela de Pessoas para fazermos nossos teste aqui. Dê uma olhada no script de criação:

CREATE TABLE  `Pessoas` (
    `pes_cod` INT NOT NULL ,
    `pes_nome` VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL ,
    `pes_idade` INT NOT NULL ,
    PRIMARY KEY (  `pes_cod` )
) ENGINE = INNODB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Muuuito bem! A esta altura nós já temos os arquivos base para a conexão com o banco de dados E o banco de dados! Vamos continuar a codificar mais algumas classes e veremos o quão fácil o Spring tornou o acesso aos dados através do JDBC para nós.

Já que temos a tabela pronta no banco de dados, precisamos desenvolver uma classe Java que irá representar cada registro dessa tabela (para manipulação em memória né…):

Pessoa.java

public class Pessoa {
 
    private int cod;
    private String nome;
    private int idade;
 
    public Pessoa() {
        this.cod = -1;
        this.nome = "Não Encontrado";
        this.idade = -1;
    }
 
    public int getCod() {
        return cod;
    }
 
    public void setCod(int cod) {
        this.cod = cod;
    }
 
    public int getIdade() {
        return idade;
    }
 
    public void setIdade(int idade) {
        this.idade = idade;
    }
 
    public String getNome() {
        return nome;
    }
 
    public void setNome(String nome) {
        this.nome = nome;
    }
 
    @Override
    public String toString() {
        return "Codigo: " + String.valueOf(this.cod)
                + " | Nome: " + this.nome
                + " | Idade: " + String.valueOf(this.idade);
    }
}

Pronto, com a classe Pessoa agora fica bem mais fácil nós termos uma “Pessoa” em memória! Vamos daqui pra frente tentar unir a classe Pessoa que acabamos de escrever com o banco de dados, ou seja, inserir um objeto da classe Pessoa no banco de dados, recuperar um objeto Pessoa do banco, e por ai vai…

Caso você acompanha este blog regularmente, já deve ter percebido que eu virei fã de utilizar as interfaces no desenvolvimento (os motivos são muitos! então apenas acredite: compensa!). Já que eu sou um cara que gosta de seguir padrões e tudo mais, vamos codificar uma interface que será muito útil para o nosso acesso ao banco de dados:

IBanco.java

public interface IBanco {
 
    public void InserirPessoa(Pessoa pessoa);
 
    public void AtualizarPessoa(Pessoa pessoa);
 
    public void ApagarPessoa(Pessoa pessoa);
 
    public Pessoa SelecionarPessoa(Pessoa pessoa);
}

Esta interface obriga a classe que implementá-la a dar suporte para as operações CRUD referêntes aos objetos Pessoa juntamente com a tabela do banco de dados Pessoa (ficou meio confusa essa frase? hehehe).

Como o código sempre resolve tudo, vamos a ele que você irá entender do que eu estou falando:

BancoDados.java

public class BancoDados implements IBanco {
 
    private JdbcTemplate jdbcTemplate;
 
    public BancoDados() {
    }
 
    public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }
 
    public void InserirPessoa(Pessoa pessoa) {
        String sql = "INSERT INTO Pessoas(pes_cod,pes_nome,pes_idade) VALUES(?,?,?)";
        jdbcTemplate.update(sql, new Object[]{pessoa.getCod(), pessoa.getNome(), pessoa.getIdade()});
    }
 
    public void AtualizarPessoa(Pessoa pessoa) {
        String sql = "UPDATE Pessoas SET pes_nome = ?, pes_idade= ? WHERE pes_cod = ?";
        jdbcTemplate.update(sql, new Object[]{pessoa.getNome(), pessoa.getIdade(), pessoa.getCod()});
    }
 
    public void ApagarPessoa(Pessoa pessoa) {
        String sql = "DELETE FROM Pessoas WHERE pes_cod = ?";
        jdbcTemplate.update(sql, new Object[]{pessoa.getCod()});
    }
 
    public Pessoa SelecionarPessoa(Pessoa pessoa) {
        String sql = "SELECT * FROM Pessoas WHERE pes_cod = ?";
 
        List resultados = jdbcTemplate.query(sql, new Object[]{pessoa.getCod()},
                new RowMapper() {
 
                    public Object mapRow(ResultSet rs, int i) throws SQLException {
                        Pessoa p = new Pessoa();
                        p.setCod(rs.getInt("pes_cod"));
                        p.setNome(rs.getString("pes_nome"));
                        p.setIdade(rs.getInt("pes_idade"));
                        return p;
                    }
                });
 
        Pessoa pes = new Pessoa();
        if (resultados.size() > 0) {
            pes = (Pessoa) resultados.get(0);
        } else {
            pes.setCod(pessoa.getCod());
        }
 
        return pes;
    }
}

Muito bem, vamos com calma…

A primeira coisa que devemos notar é que temos uma variável de instância chamada jdbcTemplate. Como eu imagino que você leitor é um cara que associa tudo muito rápido e já viu que um pouco mais pra baixo dessa variável tem o setter dela, eu imagino que você já entendeu que essa variável vai ser injetada através do container do Spring né… =]

Como nós já pedimos pro Spring criar um bean do tipo JdbcTemplate no arquivo de configuração, daqui a pouco nós voltaremos nele e pediremos pra ele enviar uma referência do JdbcTemplate aqui pra essa nossa classe poder usar. Tudo muito prático!

Depois disso o que nós podemos entender é que a classe reescreveu os métodos que a interface obriga e os implementou de fato! Vamos entender eles rapidinho…

Para as operações de inserção, alteração e exclusão os métodos são absolutamente iguais: primeiro foi definido o SQL referente a operação e depois foi chamado o método update da nossa classe super amigável: jdbcTemplate.

Existem dois detalhes para chamar a atenção na execução destas operações:

1 – O SQL que foi montado não possui os valores finais. Ao invés deles estão presentes pontos de interrogação ( ? ) representando parâmetros.

2 – Os parâmetros informados no SQL são enviados como o segundo parâmetro do método update do jdbcTemplate. Para a padronização na chamada do método é necessário que todos os parâmetros definidos no SQL sejam passados dentro de um vetor de Object (mesmo que seja só um parâmetro, ele também deve estar dentro do vetor). Outra coisa que vale ser lembrada é que o primeiro item do vetor irá ser incluído no lugar do primeiro parâmetro do SQL (primeiro ponto de interrogação) então tome cuidado para passar os parâmetros na ordem correta para o vetor de Object.

Só mais um comentário para a operação de seleção: também foi utilizado um SQL com parâmetro e um vetor de Object referenciando os parâmetros porém o método do jdbcTemplate utilizado não foi o update, e sim o query!

O funcionamento deste método é bem interessante: ao invés de apenas 2 parâmetros (como no método update), depois do vetor de Object é passado um objeto org.springframework.jdbc.core.RowMapper que é responsável por mapear cada registro retornado por um ResultSet interno ao jdbcTemplate em um objeto correspondente ao registro e após o mapeamento o objeto customizado é adicionado a um java.util.List que é o retorno final do método query.

Exemplo do nosso caso: caso sejam retornadas 3 pessoas pelo SQL utilizado, o método mapRow do objeto RowMapper será invocado 3 vezes (uma para cada registro). Cada vez que ele for invocado será configurado um novo objeto Pessoa com os dados de cada registro retornado do banco de dados e cada vez que o método retornar um novo objeto Pessoa ele será guardado na lista que será retornada pelo método query.

Logo depois deste método eu apenas retorno o primeiro objeto que está na lista ou então retorno um objeto com o mesmo código da busca caso não foi encontrado nenhum registro.

Sempre muito simples esses códigos… adoro isso… ehheheh

Vamos adicionar um bean ao arquivo de configuração do Spring para o container também instanciar a nossa classe responsável pelo banco de dados e é claro, vamos também já injetar o JdbcTemplate no nosso novo bean:

 version="1.0" encoding="UTF-8"?>
 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-2.0.xsd">
 
     id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
         name="driverClassName" value="com.mysql.jdbc.Driver" />
         name="url" value="jdbc:mysql://localhost/spring_jdbc" />
         name="username" value="root" />
         name="password" value="123" />
    >
 
     id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
         name="dataSource" ref="dataSource" />
    >
 
     id="banco_dados" class="spring_jdbc.BancoDados">
         name="jdbcTemplate" ref="jdbcTemplate" />
    >
 
>

E isso é tudo!!
Nossas classes base para o acesso e manipulação da entidade Pessoa no banco de dados e no nosso próprio software já estão codificadas e bem funcionais. Tudo que precisamos agora é de um programinha exemplo para testarmos estas classes e ver como iriam ser realmente usadas.

Segue a classe que contém o método main desta aplicação:

public class Principal {
 
    public static void main(String[] args) {
        ApplicationContext ctx = new ClassPathXmlApplicationContext("/conf/spring_jdbc.xml");
 
        BancoDados banco = (BancoDados) ctx.getBean("banco_dados");
 
        //cria os objetos Pessoa
        Pessoa p1 = criar_pessoa(1, "Felipe", 18);
        Pessoa p2 = criar_pessoa(1, "Felipe Saab", 21);
        Pessoa felipe = null;
 
        //insere no banco
        try {
            banco.InserirPessoa(p1);
            System.out.println("1 - Pessoa Inserida");
        } catch (Exception e) {
            System.out.println("Não foi possível inserir o registro: " + e);
        }
 
        //recupera
        try {
            felipe = banco.SelecionarPessoa(p1);
            System.out.println("2 - Pessoa recuperada: " + felipe);
        } catch (Exception e) {
            System.out.println("Não foi possível recuperar o registro: " + e);
        }
 
        //altera
        try {
            banco.AtualizarPessoa(p2);
            System.out.println("3 - Pessoa Atualizada");
        } catch (Exception e) {
            System.out.println("Não foi possível atualizar o registro: " + e);
        }
 
        //recupera novamente
        try {
            felipe = banco.SelecionarPessoa(p2);
            System.out.println("4 - Pessoa recuperada: " + felipe);
        } catch (Exception e) {
            System.out.println("Não foi possível recuperar o registro: " + e);
        }
 
        //apaga
        try {
            banco.ApagarPessoa(p2);
            System.out.println("5 - Pessoa Apagada");
        } catch (Exception e) {
            System.out.println("Não foi possível apagar o registro: " + e);
        }
 
        //procura pela ultima vez
        try {
            felipe = banco.SelecionarPessoa(p2);
            System.out.println("6 - Pessoa recuperada: " + felipe);
        } catch (Exception e) {
            System.out.println("Não foi possível recuperar o registro: " + e);
        }
    }
 
    public static Pessoa criar_pessoa(int cod, String nome, int idade) {
        Pessoa p = new Pessoa();
        p.setCod(cod);
        p.setNome(nome);
        p.setIdade(idade);
        return p;
    }
}

Concordo que o exemplo é meio grandinho mas é bem fácil de entender não é?
Primeiro foram criados 3 objetos Pessoa (p1 – “Felipe”, p2 – “Felipe Saab” e felipe que irá receber o resultado da busca no banco), depois foi inserido um dos objetos, procurado por ele no banco, depois ele foi alterado com as informações do outro objeto e foi recuperado novamente, e por fim a Pessoa foi apagada do banco e só para garantir foi feita uma última busca.

Este exemplo foi só para testar todas as operações que nós implementamos. Caso você use algo parecido no seu software do dia a dia irá ver que tudo funciona perfeitamente bem (cada operação no teu lugar certo).

É isso ai leitor! Você chegou ao fim deste post grandão!!
Espero que tenha gostado da leitura e da função que foi descrita aqui.

Caso queira fazer o download do projeto que eu desenvolvi como exemplo pode fazer o download aqui (OBS: o projeto está com bibliotecas do NetBeans 6.8 (Spring 2.5 e MySQL JDBC) então ele só vai rodar 100% certo caso você abra ele no NetBeans 6.8 ou superior, caso contrario, apenas aproveite os códigos fonte =] ).

[]s e até a próxima,
Saab.

Spring Framework Parte 2 -> Aspect Oriented Programming

Felipe Saab — Wed, 11 Aug 2010 19:53:43 +0000

Considerações iniciais: se vc veio ler este post e ainda não leu o post anterior (Spring Framework Parte 1 -> Dependency Injection), por favor o faça! Caso contrário você pode não entender os códigos utilizados aqui.

Beleza, daqui pra frente vou assumir que você já sabe como linkar os beans no Spring utilizando o arquivo de configuração (pelo menos o básico, como visto na Parte 1 desta série).

Vamos ao nosso post então: AOP: Aspect Oriented Programming (POA: Programação Orientada a Aspectos). E como sempre, pra fugir um pouco dos termos técnicos, vamos a uma história:

Imagine que você está desenvolvendo um e-commerce, atualmente está desenvolvendo o checkout do teu sistema, ou seja, o cliente já escolheu tudo o que ele queria, e agora vai fazer a transferência eletrônica do pagamento (vamos imaginar que você está desenvolvendo tudo isso). Olhando com um nível de abstração muito alto o seu código poderia ser algo assim:

public class CheckoutService {
    //...
    public void efetuarPagamento(Carrinho carrinho){
        LOGGER.log(new Date().toString() + " - Executando efetuarPagamento(Carrinho carrinho)");
        if (carrinho.getCliente().temPermissao()){
             DAO.iniciarTransacao();
             try {
                 carrinho.getCliente().debitar(carrinho.getValorTotal());
                 carrinho.finalizarCompra();
                 DAO.commit();
                 LOGGER.log(new Date().toString() + " - Pagamento efetuado!");
             } catch (Exception e) {
                 DAO.rollback();
                 LOGGER.log(new Date().toString() + " - " + e.toString());
             }
        } else {
            LOGGER.log(new Date().toString() + "Cliente não está autenticado");
        }
    }
    //...
}

Dê uma boa olhada no código… O que tem a ver mesmo com o checkout são apenas as linhas:

carrinho.getCliente().debitar(carrinho.getValorTotal());
carrinho.finalizarCompra();

O resto é código responsável por logging, controle de transação, permissão de acessos, coisas que são necessárias porém que ocupam muito espaço, “sujam” o código. A idéia da orientação a objetos é encapsular em um objeto todas as coisas referentes a ele, os serviços que ele vai prestar, e não ficar poluindo ele com outros códigos que não tem nada a ver com o seu propósito.

Mas esses códigos são necessários para a aplicação funcionar corretamente! O que fazer então? Orientação a Aspectos!!!

A Orientação a Aspectos surgiu exatamente para eliminar os cross-cutting concerns (código que é necessário, porém foge das preocupações principais do objeto, como no caso acima, o checkout tem que se preocupar com o logging, transação e permissão).

OBS: Existem vários termos técnicos, sem graça, e difíceis de entender envolvidos nesse “paradigma” de programação. Nós vamos discutindo-os conforme o tutorial for andando.

Então como eu faço para separar esse código chato dos meus objetos? A Orientação a Aspectos funciona assim:

-> Primeiro a gente separa o código que não tem nada a ver com o nosso objeto (logging, transação, permissão e tals) em um lugar separado. Esse lugar separado se chama advice (é o o que).

-> Ainda dentro do advice, é definido onde o programa tem que dar uma “paradinha” para que o código que foi separado possa ser executado. Todo lugar que o programa pode dar essa “paradinha” é chamado de join point. Um join point pode ser por exemplo: uma chamada de método, a execução de um método, instanciação de objetos, execução de construtores, e mais alugns (é o quando).

-> Uma vez que nós já sabemos o que vai ser feito (advice) e quando vai ser feito (join point), falta definir onde vai ser feito. Para isso servem os pointcuts. Geralmente são definidos utilizando os nomes das classes e métodos que queremos interceptar, mas também podem ser definidos através de expressões regulares (logo mais veremos um exemplo na prática).

-> Por fim, o conjunto de tudo isso (o que vai ser feito, quando vai ser feito e onde vai ser feito) é chamado de aspect (aspecto).

Em ~~muito~~ poucas palavras isso é a base da orientação a aspectos. Vamos ver como a gente pode utilizar isso no Spring.

O Spring oferece diversos tipos de suporte a Orientação a Aspectos (eles foram evoluindo através das versões), dentre eles o suporte para a orientação a aspectos declarativa (no XML de configuração) e anotativa (utilizando annotations (se não sabe o que são annotations clique aqui)).

Eu estudei as duas e devo dizer que me identifiquei muito mais com a orientação a aspectos utilizando annotations, portanto é ela que eu irei mostrar aqui (caso queira aprender sobre o outro tipo eu aconselho fortemente o livro Spring in Action 2 (Manning, 2008), capítulo 4).

OBS: Eu irei reaproveitar o código da Parte 1, então caso você não tenha feito o tutorial anterior eu aconselho a pelo menos pegar os código de lá. Tudo o que eu fiz foi renomear o projeto para “OrientacaoAspectos”, o pacote principal para “orientacaoaspectos” e todas as definições dos beans no arquivo de configuração para bater com o novo nome do pacote.
Como o suporte de orientação a aspectos do Spring consegue usar a poderosa linguagem do AspectJ (para definir pointcuts) nós vamos usá-la aqui, para tanto é necessário o download da biblioteca do AspectJ e a inclusão dela no classpath. O arquivo pode ser baixado no site do projeto.
Só mais um detalhe: o arquivo que vc baixa do site eh um .jar chamado: aspectj-x.x.x.jar, dentro dele é que estão as bibliotecas que o Spring precisa, então abra este arquivo com o WinRAR (ou outro do gênero) navegue até a pasta /lib, extraia os .jar que estão lá e os adicione ao classpath.

Voltando ao escopo da nossa aplicação: o show de talentos Ídolos Spring, vamos adicionar um requisito muito importante para qualquer programa de entrenimento: a platéia!

Sem utilizar a orientação a aspectos nós teríamos os seguintes códigos:

public class Plateia {
 
    public Plateia() { }
 
    public void sentar(){
        System.out.println("A platéia está sentando");
    }
 
    public void desligarCelulares(){
        System.out.println("A platéia está desligando os celulares");
    }
 
    public void aplaudir(){
        System.out.println("CLAP CLAP CLAP UHULL CLAP CLAP");
    }
 
    public void vaiar(){
        System.out.println("UUUUUU!! E FORA! E FORA! UUUUU!! ");
    }
}

public class Cantor implements Competidor {
 
    private Musica musica;
    private Plateia plateia;
 
    public Cantor() {
    }
 
    public void setMusica(Musica musica) {
        this.musica = musica;
    }
 
    public void setPlateia(Plateia plateia) {
        this.plateia = plateia;
    }
 
    public void apresentar() {
        plateia.sentar();
        plateia.desligarCelulares();
 
        try {
            musica.cantar();
            plateia.aplaudir();
        } catch (Exception e) {
            plateia.vaiar();
        }
    }
}

OBS: A platéia estaria sendo injetada na classe Cantor pelo container assim como está acontecendo com a musica.

Sem a orientação a aspectos, toda classe que implemente a interface Competidor tem que ficar se preocupando com a platéia. Não é certo o competidor ficar mostrando os assentos para a platéia, pedir para elas desligarem os celulares, se apresentar e por fim pedir para eles aplaudirem ou vaiarem. Isso é coisa que a platéia tem que fazer sozinha!

Vamos utilizar todo o poder da orientação a aspectos para que a platéia consiga fazer isso sozinha. A classe Cantor volta a ser o que era antes, se preocupando somente em cantar a sua musica:

public class Cantor implements Competidor {
 
    private Musica musica;
 
    public Cantor() {
    }
 
    public void setMusica(Musica musica) {
        this.musica = musica;
    }
 
    public void apresentar() {
        musica.cantar();
    }
}

E a classe Plateia vai ser “anotada” para utilizar as funcionalidades da orientação a aspectos:

@Aspect
public class Plateia {
 
    public Plateia() { }
 
    @Pointcut("execution(* *.apresentar(..))")
    public void apresentacao() {}
 
    @Before("apresentacao()")
    public void sentar(){
        System.out.println("A platéia está sentando");
    }
 
    @Before("apresentacao()")
    public void desligarCelulares(){
        System.out.println("A platéia está desligando os celulares");
    }
 
    @AfterReturning("apresentacao()")
    public void aplaudir(){
        System.out.println("CLAP CLAP CLAP UHULL CLAP CLAP");
    }
 
    @AfterThrowing("apresentacao()")
    public void vaiar(){
        System.out.println("UUUUUU!! E FORA! E FORA! UUUUU!! ");
    }
}

Aconteceram algumas coisas aqui:

-> Primeiro de tudo, a classe foi anotada com a anotação @Aspect indicando o óbvio: esta classe será um aspecto;

-> Depois foi criado um método que não faz absolutamente nada chamado apresentacao() cujo único propósito deste método é ser anotado para se “tornar” um pointcut (“tornar” entre aspas porque apresentar() continua sendo um método que não faz nada, apenas contém uma anotação que é um pointcut).
O parâmetro passado para a anotação @Pointcut é uma frase na linguagem de descrição de pointcuts do AspectJ. Segue uma pequena explicação dela (que eu acabei de fazer no Paint!! hehehe):

-> Depois que o pointcut está definido, basta anotar os métodos desejados especificando quando e onde eles devem ser executados. Para especificar onde os métodos serão executados é utilizado o nome do método que está anotado com o pointcut (no nosso exemplo é a string “apresentacao()”) e para especificar quando existem algumas outras anotações. Creio que as mais utilizadas são: @Before, @AfterReturning e @AfterThrowing (caso queira saber quais são as outras, fique a vontade para fuçar na documentação).

E voilá, nosso aspecto está pronto! Para ele funcionar só falta mais uma coisinha, que não é tão pequena assim (pelo menos na teoria, na prática é sim! ).

Para a orientação a aspectos funcionar devem ser criadas cópias dos objetos que queremos interceptar. Tais cópias contém os advices (códigos das cross-cut concerns) e esse objeto é que recebe as requisições, executa os advices e depois passa a requisição para o método do objeto original. Essas cópias de objetos que contém os advices são chamados de Proxy (no plural: Proxies).

E até algumas versões atrás os proxies tinham que ser criados na mão!!! Imagine que trabalho que dava… Porém o Spring provê um mecanismo automático para a criação dos proxies (ufa!).

Segue o arquivo de configuração para podermos fazer nosso exemplo funcionar:

 version="1.0" encoding="UTF-8"?>
 xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:aop="http://www.springframework.org/schema/aop"
        xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
            http://www.springframework.org/schema/aop
            http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
 
       
        id="atireiopau" class="orientacaoaspectos.AtireiOPauNoGato" />
        id="jose" class="orientacaoaspectos.Cantor">
            name="musica" ref="atireiopau" />
       >
 
        id="ciranda" class="orientacaoaspectos.CirandaCirandinha" />
        id="gaita" class="orientacaoaspectos.Gaita" />
 
        id="piano" class="orientacaoaspectos.Piano" />
        id="carlos" class="orientacaoaspectos.CantorTocador">
            name="musica" ref="atireiopau" />
            name="instrumento" ref="piano" />
       >
 
       
        class="orientacaoaspectos.Plateia" />
        />
>

Três coisas novas apareceram no arquivo de configuração:

1 – Na root tag () foi definido mais um namespace (xmlns:aop) e na localização dos esquemas estão os seus respectivos links. Isso é necessário para o arquivo de configuração saber quais tags podem e quais não podem quando o assunto é AOP;

2 – Foi declarado o bean correspondente à platéia. Ele não tem o atributo id definido porque provavelmente nós nunca precisaremos de uma referência à platéia, eles fazem tudo sozinhos! Não tem porque darmos um id para a platéia sendo que nunca iremos utilizá-la;

3 – A simples tag “< aop:aspectj-autoproxy />” já diz para o Spring fazer todo o trabalho duro de ficar criando os proxies para nós.

E é isso caro leitor(a) (será que mulher le isso? to brincando!! hehehe), agora é só compilar (in the java-way of course), pedir pra tia VM executar e ver a platéia trabalhando sozinha, que povo educado!

Saindo da historinha e voltando ao mundo real, é extremamente fácil prover um mecanismo de log simples e que pode sofrer modificações facilmente utilizando a programação orientada a aspectos. Suponha que sua aplicação utilize o mecanismo padrão de log do Java e queira mudar para o Log4J: simples! Basta ir no seu aspecto responsável pelo log, e alterar os códigos. Você só tem trabalho uma vez (e nem é tanto trabalho assim)!

Nos próximos posts veremos os mecanismos que o Spring provê para banco de dados, transações, segurança, e mais alguns. Tão fácil quanto um System.out.println(“Hello World”).

Quem quiser o código do projeto, está aqui.

[]s e até a próxima,
Saab.