Parte I - Introdução
De uns tempos para cá tenho percebido uma procura crescente por
ferramentas que facilitem a integração entre o mundo orientado a objetos (a
linguagem e o framework) e o mundo relacional (o banco de dados). As tais
ferramentas de mapeamento objeto relacional nada mais são do que um "tradutor"
entre duas línguas totalmente diferentes.
Em todas as traduções você acaba perdendo as sutilezas de uma
língua ou tendo que usar muito mais palavras para expressar um conceito que é
relativamente simples na língua de origem. No mapeamento O/R não é diferente:
você acaba perdendo uma série de recursos da programação OO, ou tendo que
escrever muito mais código para simular no banco de dados algo simples na
linguagem (como por exemplo, uma propriedade do tipo array ou o gerenciamento de
uma herança).
Particularmente acredito que estaremos em um mundo perfeito
quando todos os banco de dados permitirem que você simplesmente pegue seu objeto
do jeito que ele está e jogue-o no banco de dados(vou passar a chamar de banco
de objetos) sem se preocupar com camadas e mais camadas de código para
"traduzir" um objeto em query.
Já existem várias tentativas de se fazer isso, incluindo
algumas muito avançadas como o Prevayler (bambooprevalence e xprevail nas encarnações .Net). No entanto, a falta de
confiabilidade nos equipamentos e sistema operacional aliadas a uma certa dose
de preconceito fazem com que essa solução ainda seja rotulada como "algo para o
futuro".
Na outra ponta existem soluções como o LINQ da
Microsoft, uma feature que estará disponível oficialmente no C# 3.0 mas que já
pode ser testado agora. Não considero que isso seja verdadeiramente uma solução
pois misturar conceitos relacionais (selects, wheres, etc) em uma linguagem OO
como o C# é o que poderíamos chamar de "código alienígena".
Um banco realmente OO deve permitir que você faça suas
consultas de forma orientada a objetos, como se estivesse pesquisando em uma
Array, List ou qualquer outro container de objetos.
É aqui que se encaixa o
db4o! Claro que existem outras soluções como o Caché, mas prefiro me ater
ao db4o pelo seu custo acessível e por já estar mais integrado a plataforma
.Net
db4objects
O db4objects(db4o) surgiu a alguns anos atrás inicialmente
apenas para Java. Com a grande semelhança de código entre o .Net e o Java, foi
um pulo para que fosse criada uma versão .Net. Hoje, as versões .Net e Java
caminham lado a lado, tendo ambas os mesmos recursos.
Com esse banco você pode desenvolver aplicações WEB,
Windows.forms e Compact Framework. Você não precisa instalar nem configurar um
servidor de banco de dados. Basta enviar junto com sua aplicação uma pequena
dll. Claro que você pode fazer uma aplicação cliente/servidor. O próprio db4o
provê recursos para que isso seja feito, mas sempre de uma forma simples, sem a
necessidade de ser um PHD em configuração de banco de dados.
O db4o tem um mecanismo de replicação muito útil para quem tem
necessidade por exemplo, de manter bancos off-line parte do tempo e
on-line
o restante (quem desenvolve para forças de venda deve imaginar o que estou
falando!).
Quando falo em db4o, algumas perguntas são inevitáveis:
a) Não tenho problemas de performance? Não. Alguns testes
mostram inclusive que o db4o é muito mais rápido que soluções que envolvam o uso
de Nhibernate por exemplo. Veja benchmarks aqui: http://www.db4o.com/about/productinformation/benchmarks/
b) Ele não é caro como o Caché? Não. A licença do db4o é
open-source dual como a do MySql, ou seja, se você está desenvolvendo para uso
dentro de sua empresa, criando seu website ou desenvolvendo um programa GPL, ele
é gratuito para você.
Mas mesmo que você precise distribuir sua aplicação, o
custo da licença runtime é muito baixo.