Artigo Java Magazine 42 - Dados e Mapeamento: uma Visão Total

Esse artigo faz parte da revista Java Magazine edição 42. Clique aqui para ler todos os artigos desta edição

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

Dados e Mapeamento: uma Visão Total

Explorando técnicas e tecnologias para persistência de dados

Conheça as três principais escolas para o acesso e a persistência de dados, e as vantagens e desvantagens de cada uma, enfocando o estado-da-arte em tecnologias Java

Um dos principais problemas do desenvolvimento de software, nos últimos 15 anos, quando começou a popularização da Orientação a Objetos, tem sido a compatibilização entre este paradigma e o dos bancos de dados relacionais. Já conhecemos bem a história: objetos versus tabelas; herança versus joins, encapsulamento versus projeção, e assim por diante.

O problema é resumido pela Figura 1, onde vemos uma aplicação OO escrita em Java acessando um SGBD relacional. A "Interface BDR" é a interface natural, ou "nativa", do SGBD. Para bancos relacionais, essa interface é uma combinação entre SQL e estruturas de dados e protocolos de rede otimizados para executar comandos SQL e transferir dados tabulares. O JDBC é um exemplo de API modelada segundo os requisitos destas estruturas e protocolos.

Figura 1. Aplicação OO Java acessando um banco relacional, com a necessidade de mapear os objetos para o mundo relacional (sombreado = overhead).

A aplicação OO precisará de uma camada de "mapeamento objeto-relacional", que traduz estruturas e operações do mundo OO para o mundo relacional. Embora o termo "mapeamento" seja mais usado com ferramentas que fazem isso automaticamente, toda vez que você escreve, por exemplo, um código JDBC que executa um SELECT ... FROM CLIENTE e extrai os resultados retornados para seus objetos Cliente, está fazendo mapeamento objeto-relacional, só que à mão.

Escrever esse código à mão é obviamente trabalhoso, então qual é a solução para combinar uma linguagem OO com um SGBD? Muitos desenvolvedores Java que utilizam ferramentas como o Hibernate, JDO, ou a nova JPA do EJB 3.0, podem considerar este problema já resolvido. A resposta estaria nas já citadas ferramentas de mapeamento objeto-relacional (ORM). Todavia, esta resposta se baseia em três pressupostos que podem não ser verdadeiros para todos os desenvolvedores e todos os projetos:

1.Uma "grande unificação OO" é melhor que misturar paradigmas;

2.Todos os SGBDs acessados são estritamente relacionais;

3.Ferramentas ORM acessam os dados da forma mais eficiente e produtiva.

Neste artigo, vamos explorar a questão do acesso a SGBDs, revisando diversas escolas de pensamento, e examinando as principais alternativas tanto em Java quanto em algumas outras linguagens e plataformas. Nosso plano é o de informar o leitor sobre todo o panorama das técnicas de acesso a dados. O objetivo é ajudá-lo a navegar pela multidão de ferramentas e tecnologias que competem pela fidelidade dos desenvolvedores.

Escola 1: Bancos OO

A primeira escola que abordaremos é a dos puristas OO – abandonar o paradigma relacional e utilizar bancos de dados OO puros ou, pelo menos BDs híbridos OO/relacionais. Neste caso, o banco de dados fala a língua dos objetos e tudo está resolvido, a favor do paradigma orientado a objetos.

Um banco puramente OO armazena dados organizados em hierarquias de classes, não em tabelas. Bancos OO suportam diretamente herança, polimorfismo e coleções. E suportam uma linguagem OO para consultas e para procedimentos armazenados (stored procedures). A Figura 2 mostra a arquitetura resultante. Esta arquitetura é mais simples que a da Figura 1, pois não precisamos de nenhum mapeamento, já que o banco de dados já "fala" a linguagem dos objetos – a interface de acesso ao BD é uma interface OO. Isso significa que não podemos usar nem SQL, nem JDBC, para acessar o BD, mas precisamos substituir essas tecnologias por linguagens de consultas (query languages) e APIs apropriadas ao SGBD.

Além da simplicidade (ex.: não ter que especificar nenhum mapeamento), temos também um desempenho potencialmente superior, pois não precisamos executar uma camada adicional de código de mapeamento. E tudo o mais sendo igual, quanto menos código você precisar para determinada tarefa, menos CPU estará gastando.

SGBDOOs e o padrão JDO

Um grande problema dos SGBDOOs, tradicionalmente, era a falta de padrões. Até há alguns anos, a regra era linguagens de consultas e APIs proprietárias e diferentes de um BDOO para outro. Ou seja, no lugar daquela caixinha "Interface BDOO" da Figura 2, poderíamos ler "API proprietária e não-portável". Algo especialmente ruim na comunidade Java, que valoriza a padronização e a portabilidade.

Por exemplo, com o banco db4o (que tem uma versão GPL), teremos código como o da Listagem 1 (baseada no exemplo "Formula 1" do tutorial deste banco). A classe ObjectContainer representa a conexão com a base de dados. Para localizar todos os objetos Pilot com um nome específico, criamos um objeto deste tipo (um POJO) setando somente o nome, e usamos o método ObjectContainer.get(Object), que faz uma "pesquisa baseada em exemplo". A classe ObjectSet representa o resultado de uma consulta, e ObjectContainer.delete(Object) remove o objeto. Não há como ser muito mais simples que isso. O problema é que as classes com.db4o.* constituem uma API totalmente proprietária. Se você mudar, por exemplo, para o banco de dados Caché, terá que revisar todo o seu código para utilizar a API com.intersys.* deste outro SGBDOO.

public static void deleteFirstPilotByName (ObjectContainer db) {

ObjectSet result = db.get(new Pilot("Michael Schumacher"));

Pilot found = (Pilot)result.next();

db.delete(found);

}

Mas a solução para essa questão da portabilidade veio com a norma ODMG 3.0 do Object Data Management Group[1], que normatiza o modelo de dados, a linguagem de consultas e a persistência de objetos em bancos OO, OO/relacionais e relacionais (via mapeamento). No universo Java, este padrão é incorporado pelo JDO (Java Data Objects). O JDO é mais conhecido como ferramenta ORM, portanto mais usado com SGBDs relacionais. Mas na verdade o JDO 1.0" [...] continue lendo...