RMI e HIbernate... lições aprendidas

Estou participando de um projeto onde decidimos utilizar RMI para conversação de dois módulos do sistema. A decisão não vem ao caso agora, mas achei interessante gurdas alguns "causos"...

RMI e Hibernate, onde tudo começou

Como falei anteriormente, decidimos utilizar RMI para integrar dois módulos do sistema. Um módulo responsável pela parte de negócio( persistência também) e outro por uma parte específica bem baixo nível (baixo nível = bytes.. 01010101...etc...).

Então, o gênio projetista teve a seguinte idéia: "Vamos utilizar as classes persistentes para trafegar via RMI".

Resultado: LazyInitializationException -LIE.

Em um determinado método de uma classe acessada via RMI o retorno era um objeto que foi buscado do Hibernate. Este objeto tinha outros objetos, que tinham outros objetos, que tinham outros objetos... blá blá blá...

Soluções:

1º) Colocar "transient"(do java não do JPA) nos atributos que não deveriam trafegar via RMI. Puramor de Deus, Nãããão!!!

Imagina ficar colocando transiente em tudo que é atributo espalhado pelo código inteiro. Loucura!!!

2º) Modificar o design

Interessante... muito interessante...

O Design... (não é de moda porr!!)

Tentei fazer algo que representasse o problema. Então abaixo estão algumas classes de domínio, mapeadas no hibernate.

OBS: Para quem não sabe, em RMI devem existir interfaces comuns nos dois lados da comunicação. Então a interface PessoaData é conhecida pelos dois módulos.


Agora, viram o que o projetista gênio fez ?!?!?!

A classe Pessoa implementa a interface PessoaData. Na imagem acima temos somente um exemplo, mas no contexto real são umas 20 classes que irão trafegar via RMI. Todas essas classes são entidades persistentes.

Observe que a interface PessoaData retorna byte[]. Isso mesmo.. o "carinha" que utiliza estas classes vai precisar dos dados convertidos em bytes. Guarde esta informação.

Confesso que o projetista gênio(agora já deve-se saber quem é o projetista... :D ) percebeu a burrada somente quando ocorreu o erro com hibernate.

O que vocês conseguem enchergar ai?

Bom, vou dizer o que eu consegui enxergar:

• Uma classe persistente implementa uma interface utilizada para comunicação entre sistemas. Acomplamento! Entidade persistente conhece uma interface onde o objetivo é comunicação de dados entre sistemas... "nada a vê"
  
• Pelo motivo acima, a entidade persistente é responsável por converter String, Integer, Date em bytes. Coesão! Tava tudo misturado, conversões com bytes em uma classe onde o objeto é enviar e obter informações do banco de dados.

Solução tomada

Utilizamos os famosos Transfer Objects. Segue o exemplo:

Matamos o problema de coesão, onde a classe PessoaTo é responsável por trabalhar os dados para comunicação.
Matamos o problema de acomplamento onde a classe Pessoa não sabe que a classe PessoaTo existe.
Matamos o LazyInitializationException. A classe TO contém apenas o que será necessário para transferência.

Lições aprendidas

• Colocar tudo em uma classe é diferente de economizar tempo
• Preguisoço trabalha em dobro... :D
• Projetos iterativos minimizam os erros. Descobrimos o problema no início e retrabalho foi de aproximadamente 5hs.
• Enviar objetos utilizados para persistência via RMI-> ... LazyInitializationException
• Spring RMI exporter facilita muito!
• Cuidar as dependências das classes

Era isso..

Abraço!

Padrões de Projeto - Gerador de Gráficos com Template Method

Dae gurizada...

Algum tempo atrás eu e um amigo, Marcos Brião, fizemos uma oficina (workshop) na Confraria do Java, grupo de estudos da Ulbra em Canoas/RS, sobre Desgin Patterns.


Esses dias tava revirando meus arquivos e encontrei essa apresentação. Nessa oficina fizemos um Gerador de Gráficos simples com alguns patterns. O sistema ficou bem interessante.

Screenshot:

Faça os downloads:

• Apresentação (PDF)
• Aplicação Exemplo

Essa aplicação basicamente gera gráficos com informações digitadas na tela. Com o uso de Design Patterns como Template Method e Facade, conseguimos ter uma aplicação fácil de fazer manutenção e entendimento.
Utilizamos o framework JFreeChart(link) para gerar os gráficos.

Esse é o diagrama de classes:




Template Method
Definição:

Definir o esqueleto de um algorítimo em uma operação, postergando (deferring) alguns passos para subclasses. Template Method (Gabaríto de Método) permite que subclasses redefinam certos passos de um algorítimo sem mudar a estrutura do mesmo.

Padroes de Projeto -GoF

Vamos imaginar um algorítimo qualquer, com esse exemplo, gerar gráficos.

Quando vamos gerar gráficos a lógica para criar o ojeto JFreeChart é sempre a mesma. A única parte que muda, de um gráfico para outro, é quando vamos adicionar os dados ao gráfico.

Nesse contexto poderíamos ter uma classe que faria a lógica para gerar o gráfico e quando fosse adicionar dados, passaria a responsabilidade para uma classe filha.

Fizemos exatamente isso. Temos uma classe abstrata chamda GraficoTemplate, que tem a lógica para gerar os gráficos.

Veja a classe:

Como vocês podem ver essa clase é bem simples.

Temos um método criarGráfico, que recebe uma lista de dados e retorna um objeto JFreeChart. Esse método esta declarado como final. Isso significa que nenhuma classe que extender esa classe poderá alterar essa lógica. Esse detalhe do método ser final não faz parte do padrão Template Method.

Dentro do método criarGrafico eu chamo dois métidos: "carregarDados" e "configurarLegenda".

O método "configurarLegenda" é implementado dentro dessa classe mesmo. Ou seja, tem uma implementação padrão, mas qualquer classe que pode sobrescrever o método e alterar essa configuração de legenda.

O método "carregarDados", muita anteção! Aqui que está o Pattern.

Viu que o método esta marcado como "abstract" e por isso não tem implemetação ?

Na linguagem java todo método declarado como "abstract" indica que esse método deverá ser implementado na primeira classe concreta que estender essa classe.

O comportamento é igual ao de uma interface. Até por que uma interface, para o compiladora java, é uma classe abstrata com métodos abstrados, mas isso é outra história.

Vamos ver uma classe que estende a GraficoTemplate.

Vamos ver a classe que gerar o grafico de Pizza:


A classe GraficoPizza estende a GraficoTemplate e, obrigatoriamente, implementa o método "carregarDados(List dados)".

É aqui, na classe filha, que é definido como será carregado o gráfico.

Simplesmente itero a lista e populo o objeto "grafico", que está definido como protected na classe GraficoTemplate.

Veja que nessa implementação eu usso o método "createPieChart3D" da classe ChartFactory.

Quando fomos implementar outra classe, como a GraficoLinha, esse método "carregarDados" será diferente.

Veja:

A implementação do método "carregarDados" na classe "GraficoLinha" está um pouco diferente.


Esse exempo é bem simples. Mas se você conseguiu entender a "lógica"do pattern com certeza irá utlizar muitas vezes esse.

O que fizemos aqui é delegar parte da lógica de gerar gráficos para suas classes filhas.

Você pode estar pensando que a lógica que está no classe GraficoTemplate é bem simples. E realmente é. Mas poderías implementar nela outros métodos como alterar as cores do gráfico, definir um padráo de tamaho, etc..

Isso seria simples e se aplicaria a todos os gráficos da aplicação.


Esse exemplo foi construído para explicar, de forma simples, a lógica de 1 padrão de projeto e como é vantajoso sua utilização.

Tem pontos da aplicação que estão "feias" quanto a Design. Como por exemplo, não ter utilizado interfaces e utlizar Array de object para transferir dos dados da View para os gráficos.


Mas, nem tudo é perfeito...heheheh

Conforme irei estudando os Design Patterns vou postando ai...

Mais uma vez: Críticas sempre são bem vindas, obrigado.

Abraço a todos!