Muita gente me faz a pergunta: “Que solução utilizar para persistência de dados?” Eu inclusive já abordei esse assunto aqui no Blog quando falei do futuro do LINQ to SQL:
Minha resposta na maioria das vezes é: Depende do Projeto.
Se você tem um projeto de pequeno ou médio porte ou de prazo apertado, eu sugiro as soluções que vão simplificar o trabalho e aumentar a produtividade. Particularmente eu uso os DataSets Tipados do ADO.NET que atendem bem a estes cenários.
Agora, se você tem prazo sobrando e vai desenvolver um projeto relativamente grande, vale a pena investir tempo em frameworks de mapeamento objeto/relacional, como nHibernate e ADO.NET Entity Framework. Vale também planejar sua aplicação em camadas, utilizando algum padrão de projeto que vise à reutilização de código. Certamente você terá ganhos a longo prazo.
Mas no geral eu sempre tive um pé atrás com soluções de mapeamento objeto/relacional, ou padrões que criam complexos mecanismos de gravação/recuperação de dados. Além de tornarem tudo mais trabalhoso, o mercado está inundado de soluções que visam resolver o problema de incompatibilidade entre a orientação a objetos e os bancos de dados relacionais. O que dá a entender que não existe “A solução definitiva”. O que temos são variadas formas de se driblar este problema, cada uma delas com seus benefícios e defeitos.
Recentemente eu tenho dado atenção a outro tipo de solução para este problema: Os Bancos de Dados Orientado a Objetos. Não vou entrar nos detalhes de siglas e definições deste tema, basta saber que há muita gente desenvolvendo databases ou frameworks que armazenam os dados na forma de Objetos, e não em estruturas relacionais.
Um deles que dou destaque neste post, é o db4o (sigla de db4objects) http://developer.db4o.com/. Este database orientado a objetos foi criado inicialmente para Java, mas hoje tem uma ótima versão para .NET. No link citado você encontra o download da última versão, logo na primeira página.
De forma bem resumida posso dizer que as principais características do db4o são:
• É simples de usar, basta usar uma única DLL para as operações básicas;
• Comporta soluções locais e também Client/Server;
• É Open Source, e GPL pra quem é GPL;
• Compatível com varias formas de Query, como QBE e o LINQ do .NET;
• Possuí ferramentas de gerenciamento e configuração para ambientes de servidor;
• Comporta ambientes de replicação;
• Possuí uma versão para o .NET Compact Framework e para o Projeto Mono;
• Tem uma comunidade de desenvolvedores e usuários muito ativa;
Hoje se alguém me faz a pergunta lá de cima, eu sugiro considerar essa opção também, principalmente se o uso de um Banco de Dados Relacional não é pré-requisito do projeto.
Com certeza é difícil vender essa idéia, afinal os bancos de dados relacionais tem dominado o mercado ja a algum tempo. Mas de modo prático pro cliente final não muda nada. O que certamente vai melhorar com o uso de uma ferramenta como o db4o, é a sua produtividade, e esse benefício pode ser repassado para o cliente final em forma de redução de custos.
Mas vale a pena ficar por dentro de como um banco de dados orientado a objetos funciona, e quais são os benefícios e problemas frente aos relacionais. É por isso que eu vou começar a abordar este assunto aqui em futuros posts, de forma mais detalhada e com demonstrações técnicas. Se você tiver interesse em conhecer mais, também começarei a publicar alguns artigos nas edições impressas da .NET Magazine sobre esse tema. E também vídeo-aulas no Portal da DevMedia (www.devmedia.com.br). Aguarde e confira!
Grande Abraço!
