É 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.

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:

<?xml version="1.0" encoding="UTF-8"?>
<beans 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">
 
       <!-- competidores -->
       <bean id="atireiopau" class="orientacaoaspectos.AtireiOPauNoGato" />
       <bean id="jose" class="orientacaoaspectos.Cantor">
           <property name="musica" ref="atireiopau" />
       </bean>
 
       <bean id="ciranda" class="orientacaoaspectos.CirandaCirandinha" />
       <bean id="gaita" class="orientacaoaspectos.Gaita" />
 
       <bean id="piano" class="orientacaoaspectos.Piano" />
       <bean id="carlos" class="orientacaoaspectos.CantorTocador">
           <property name="musica" ref="atireiopau" />
           <property name="instrumento" ref="piano" />
       </bean>
 
       <!-- platéia -->
       <bean class="orientacaoaspectos.Plateia" />
       <aop:aspectj-autoproxy />
</beans>

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.

Annotations… recurso interessante.

Sempre tive a curiosidade de saber como funcionavam, então fui perguntar pro Google.
Pretendo demonstrar aqui o que eu aprendi nas minhas pesquisas.

Annotations são… advinhem… anotações! É um jeito que você tem de fazer alguma marcação em um atributo, método, classe, entre outros.

Elas sempre devem ser digitadas antes do objeto que você queira anotar (método, atributo…) e o nome das anotações são sempre precedidos de @ (arroba). Ex:

@MinhaAnotacao
class MinhaClasse{
}

Até ai tudo bem, mas você deve estar se perguntando: “Pra que diabos eu vou usar isso? Pra que ficar enfeitando meu código?”. Calma. Tudo tem seu propósito.

Para poder trabalhar com as anotações, iremos utilizar a reflexão computacional, portanto sugiro que você leitor, leia meus posts antigos sobre Reflexão Computacional:

Java e seus Espelhos: Reflexão Computacional e

Reflexão Computacional: Exemplo Prático

Daqui pra frente vou supor que você entende e sabe utilizar a reflexão computacional…

Exemplo 1: Testando seus métodos

Então vamos lá: imagine que você é um bom programador com uma ótima noção de engenharia de software (o que realmente deve ser verdade neh… ). Você sabe que uma fase importante no desenvolvimento de um software é a fase de testes. Porém você não gosta dos frameworks existentes para teste unitário (ou qualquer outro tipo), então você decide criar o seu próprio!

Para não ficar muito chato de utilizar, você decide que durante o desenvolvimento, todo método que possuir a anotação “@Testar” será testado pelo seu framework.

OK, com essa idéia na cabeça vamos criar a nossa anotação @Testar:

Testar.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Testar { }

Reparem que a nossa anotação deve ser anotada com meta-anotações.

A anotação @Retention(RetentionPolicy.RUNTIME) diz que a VM deve manter essas anotações em tempo de execução para podermos ler elas através da reflexão. Outras opções seriam: SOURCE e CLASS.

E a anotação @Target(ElementType.METHOD) indica que a nossa anotação só é aplicada a métodos. Outras opções seriam: FIELD, TYPE (classe e interface), PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, e PACKAGE.

Reparem que para declarar a nossa própria anotação, deve-se utilizar “@interface” antes do nome da anotação.

Pronto! Só isso! É assim que as anotações são criadas. Uma vez que já temos ela, vamos criar a classe que irá ser testada.

ClasseParaTestar.java

public class ClasseParaTestar {
 
    @Testar
    public void metodo1() {
        throw new RuntimeException("Deu zebra!");
    }
 
    @Testar
    public void metodo2() {
    }
 
    @Testar
    public void metodo3() {
    }
 
    public void metodo4() {
    }
 
    @Testar
    public void metodo5() {
        throw new RuntimeException("Ixi maria... Erro!");
    }
 
    public void metodo6() {
    }
 
    @Testar
    public void metodo7() {
    }
 
    public void metodo8() {
    }
}

Como o propósito é só demonstrar as anotações, os métodos não fazem nada.

Beleza, agora os métodos que eu quero testar já estão “anotados”. Vamos criar a classe principal do nosso framework de testes.

Testador.java

public class Testador {
 
    public static void testar(Object obj) {
        Class<?> classe = obj.getClass();
        int passou = 0;
        int falhou = 0;
 
        System.out.println("-------------Inicio dos Testes--------------");
        for (Method m : classe.getDeclaredMethods()) {
            if (m.isAnnotationPresent(Testar.class)) {
                try {
                    System.out.print("Testando o método: "; + m.getName());
                    m.invoke(obj);
                    passou++;
                    System.out.println(" => passou!");
                } catch (Throwable t) {
                    falhou++;
                    System.out.println(" => falhou! " + t.getCause());
                }
            }
        }
        System.out.println("---------------Fim dos Testes---------------");
        System.out.println("Passaram: " + passou + ", Falharam: " + falhou);
    }
}

Simples simples (caso você entenda a reflexão)… Tudo o que a gente faz é verificar se o método possui a anotação @Testar, caso ele possua, o método é invocado. Se não ocorrer nenhuma exceção, então ele passou no teste, caso contrário ele falhou.

Para utilizar o nossa pequeno (micro) framework, basta chamar o método estático passando um objeto da nossa classe para testar:

Testador.testar(new ClasseParaTestar());

Para o nosso exemplo, você deve obter a seguinte saída:

-------------Inicio dos Testes--------------
Testando o método: metodo1 => falhou! java.lang.RuntimeException: Deu zebra!
Testando o método: metodo2 => passou!
Testando o método: metodo3 => passou!
Testando o método: metodo5 => falhou! java.lang.RuntimeException: Ixi maria... Erro!
Testando o método: metodo7 => passou!
---------------Fim dos Testes---------------
Passaram: 3, Falharam: 2

Obs: Eu tirei este exemplo da documentação oficial.

Exemplo 2: Validando seus atributos

Vamos criar uma classe genérica que faz a validação dos atributos de qualquer classe que você peça para ele validar. É claro que os atributos a serem validados devem possuir as anotações que nós vamos criar.

Vamos criar as nossas anotações então: @ValidarContemTexto e @ValidarPositivo.

ValidarPositivo.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface ValidarPositivo { }

ValidarContemTexto.java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface ValidarContemTexto {
    int min() default 1;
}

Opa! Apareceu uma coisa nova aqui. A anotação @ValidarContemTexto possui um atributo???

É isso mesmo! As anotações podem conter atributos para realizar alguma lógica durante o processamento delas.

No nosso caso, a anotação @ValidarContemTexto irá validar se o atributo que está decorado com a anotação possui pelo menos min caracteres (que por default é 1).

Reparem que a meta-anotação @Target é ElementType.FIELD, porque vamos utilizar essas anotações para decorar atributos.

A classe Usuario para o nosso teste será a seguinte:

Usuario.java

public class Usuario {
 
    @ValidarContemTexto(min = 10)
    private String login;
 
    @ValidarContemTexto(min = 20)
    private String senha;
 
    @ValidarPositivo
    private int nivel;
 
    //Construtores, getters e setters
    //...
}

O login deverá possuir pelo menos 10 caracteres, a senha deverá possuir pelo menos 20 caracteres (para garantir alguma segurança… hehehe) e o nível deverá ser um inteiro positivo maior ou igual a zero.

Vamos ver a classe responsável pela validação:

Validador.java

public class Validador {
 
    public static boolean validar(Object obj) {
        Class<?> classe = obj.getClass();
        boolean ok = true;
 
        for (Field f : classe.getDeclaredFields()) {
            f.setAccessible(true);
 
            //Annotation @ValidarPositivo
            if (f.isAnnotationPresent(ValidarPositivo.class)) {
                try {
                    int num = Integer.parseInt(f.get(obj).toString());
                    if (num < 0) {
                        ok = false;
                        throw new Exception();
                    }
                } catch (Throwable t) {
                    System.out.println(f.getName() + " deve ser um valor inteiro positivo.");
                }
            }
 
            //Annotation @ValidarContemTexto
            if (f.isAnnotationPresent(ValidarContemTexto.class)) {
                ValidarContemTexto anotacao = f.getAnnotation(ValidarContemTexto.class);
                try {
                    String texto = f.get(obj).toString();
                    if (texto.length() < anotacao.min()) {
                        ok = false;
                        System.out.println(f.getName() + " deve possuir pelo menos " + anotacao.min() + " caracteres.");
                    }
                } catch (Throwable t) {
                    System.out.println(f.getName() + ": " + t.getCause());
                }
            }
        }
        return ok;
    }
}

Quase igual ao exemplo anterior, porém nós percorremos os atributos (getDeclaredFields()) ao invés do métodos (getDeclaredMethods()).

Um if para cada anotação… nada muito novo. A única novidade aqui é a recuperação da anotação @ValidarContemTexto para poder acessar o valor que foi definido para o seu atributo min. Mas também não é nada de outro mundo.

O código a seguir cria 3 usuários e executa a validação com cada um deles:

ArrayList<usuario> usuarios = new ArrayList<usuario>();
usuarios.add(new Usuario("login", "senha", 2));
usuarios.add(new Usuario("felipesaab", "SaabRocks", -5));
usuarios.add(new Usuario("javasimples", "javasimplesjavasimples", 0));
 
for (Usuario u : usuarios) {
    System.out.println("Validando usuario: " + u.getLogin());
    if (Validador.validar(u)) {
        System.out.println("Usuário OK.");
    } else {
        System.out.println("Corrija os erros.");
    }
    System.out.println();
}

O resultado será o seguinte:

Validando usuario: login
login deve possuir pelo menos 10 caracteres.
senha deve possuir pelo menos 20 caracteres.
Corrija os erros.
 
Validando usuario: felipesaab
senha deve possuir pelo menos 20 caracteres.
nivel deve ser um valor inteiro positivo.
Corrija os erros.
 
Validando usuario: javasimples
Usuário OK.

Chegamos ao fim de mais um post aqui do Java Simples. Espero que tenham gostado, eu pelo menos achei esse assunto interessantíssimo.

Quem quiser pode pegar os arquivos que eu fiz e testei aqui.

[]s e até a próxima,

Saab.