Artigo Java Magazine 25 - Persistência Turbinada

Byte Code

Persistência Turbinada

DAOs otimizados, Caching e JDBC Avançado

A programação de mais baixo nível com JDBC pode ser a melhor solução para o acesso e atualização de dados e os conhecimentos valem para soluções O/R

A plataforma Java estreou com os applets, mas começou a ser levada a sério a partir da introdução da JDBC. Começamos com uma API de baixo nível, modelada segundo o padrão ODBC da Microsoft, que é eficiente, mas requer bastante codificação. Com o tempo surgiram soluções de persistência cada vez mais fáceis e transparentes, como o Persistent State Service (PSS) da OMG, Java Data Objects (JDO; JSR-12), Hibernate, EJB (BMP e depois CMP), Castor e dezenas de alternativas proprietárias.

Mas com o tempo também descobrimos que as soluções de alto nível, orientadas à produtividade e a técnicas OO, não servem para todos os cenários possíveis. Da mesma forma que já virou rotina se falar que nem todas as aplicações Java precisam de EJB ou de servidores J2EE ou de web services, também acontece em alguns casos de a velha API JDBC ser a melhor solução para persistência. Ou mesmo a única viável.

Este artigo explora algumas idéias de programação de bancos de dados em Java, pensando no programador que por algum motivo não quer, ou não pode, utilizar persistência automática. Não vamos nos dedicar especificamente à API JDBC – pressupomos alguma familiaridade com conexões, statements, resultsets e companhia. O plano é explorar técnicas que permitem programar diretamente em JDBC, mas com vantagens de estruturação, desempenho e produtividade. E se o seu problema é decidir entre o uso de JDBC ou de uma camada de persistência de mais alto nível, também exploramos essa questão, apresentando os pontos fortes e fracos de cada alternativa.

De JDBC a DAO

Quando a JDBC foi lançada, as primeiras aplicações feitas com a API tinham uma tendência de ser bastante desestruturadas, com código JDBC espalhado por toda a aplicação, misturado com a lógica de negócio e de GUI. A situação era bem pior do que em ambientes de desenvolvimento cliente/servidor então existentes, como o PowerBuilder ou o VisualBasic, porque Java não tinha componentes de GUI “data-aware” ou IDEs especializados em programação de bancos de dados. Com o tempo a tecnologia Java evoluiu, mas em direções diferentes dos ambientes RAD[1]. Por um lado, surgiram várias soluções de persistência objeto/relacional (O/R), mas em paralelo, houve também uma evolução das práticas de programação de BD “hardcore”, com código JDBC escrito à mão.

A mais importante evolução a partir da programação JDBC pura foi o padrão de projeto DAO (Data Access Object). A motivação deste padrão é tornar o código de persistência mais organizado, reusável e desacoplado da lógica de negócio. Temos duas entidades principais: os objetos de valor (Value Objects ou VOs) e as classes DAO. Veja um exemplo na Listagem 1.

A prática mais comum é ter uma classe de VO para cada tabela, com cada coluna mapeada para um atributo, e cada linha mapeada para uma instância do VO. Mas também podemos ter VOs definidos a partir de classes de um modelo orientado a objetos; esse modelo será mapeado para tabelas não necessariamente idênticas, um para um, às classes (por exemplo, devido à normalização). Ou podemos ter uma mistura de ambos os critérios. Em qualquer caso, o VO é um “pacote” de informações que serão preservadas no banco de dados.

O código que faz a persistência fica na classe DAO, a qual muitas vezes é implementada como uma classe utilitária sem nenhum estado – com métodos static ou seguindo o pattern Singleton. Neste artigo optamos por DAOs “stateful” (com estado) e com instâncias diferenciadas, ou seja, não-Singleton. Como podemos ver na Listagem 1, isso é útil para associar o DAO a conexões, de forma a suportar a execução de várias operações persistentes numa mesma transação – sem precisar passar a conexão como parâmetro a cada método.

DAOs e persistência objeto/relacional

Os mandamentos da programação orientada a objetos nos fariam associar a funcionalidade aos dados, por exemplo escrever ordem.update() ao invés de dao.update(ordem). Mas o desacoplamento promovido pelo DAO serve para tornar o VO independente do mecanismo de persistência. Se a implementação inicial for feita com JDBC, mas quisermos migrar para JDO na próxima versão, o encapsulamento do código de persistência nos DAOs permite fazer essa mudança com um impacto mínimo sobre o código dos VOs ou de qualquer outra parte da aplicação.

Os sistemas de persistência automática para Java mais festejados são precisamente aqueles que se distinguem por suportar persistência sobre objetos de valor, também chamados de POJOs (“Plain Old Java Objects”), em contraste a outros sistemas como o EJB/CMP (até 2.1) que exigem a implementação de uma série de interfaces para tornar um objeto “persistível”. Nestes sistemas, como o Hibernate ou o futuro EJB/CMP 3.0, a implementação do DAO é generalizada pelo framework. Em vez de termos que escrever métodos para restore, create etc., o sistema de persistência é capaz de executar estas operações para qualquer POJO. Isso é feito, em primeiro lugar, com o uso de reflection, instrumentação de bytecode (que o JDO chama de “enhancing”), ou ambos – de maneira que o sistema de persistência possa ler os atributos do POJO para fazer um update no banco de dados ou definir esses atributos após uma leitura.

Neste artigo usamos “update” em minúsculas para indicar uma modificação no banco, com os comandos SQL UPDATE, INSERT ou DELETE, ou via métodos que os executem.

Em segundo lugar, com a geração automática de código SQL para as operações de leitura, update etc. de cada POJO. Ambas as funcionalidades costumam depender também de arquivos de metadados ou descritores, que especificam o mapeamento entre tabelas e POJOs.

Os sistemas de persistência automática têm outras vantagens sobre a programação JDBC:"