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

 

-tab-count: 1">        

Nota do DevMan

Algumas das soluções que se destinam a fazer a interface entre aplicações desenvolvidas com a Orientação a Objetos e Bancos de Dados relacionais, são conhecidas como Ferramentas de Mapeamento Objeto Relacional (O/RM).

 

O Mapeamento objeto/relacional é uma técnica que visa a redução da incompatibilidade que existe entre a programação orientada a objetos e os bancos de dados relacionais. Com o mapeamento as tabelas do banco de dados são representadas através de classes, e os registros são os objetos instanciados das classes correspondentes.

 

Em tese, com a utilização de uma feramenta O/RM, o programador não precisa escrever comandos na linguagem SQL. A linguagem utilizada para o acesso e armazenamento das informações é orientada a objetos.

 

Nem todas as ferramentas que se destinam a resolver o problema de incompatibilidade da OO com os databases relacionais são O/RMs, mas todas acabam oferencendo o mesmo resultado final.

 

Segue abaixo uma lista de Ferramentas que tem o objetivo de reduzir a incompatibilidade entre OO e databases relacionais (dentre elas algumas são O/RMs). As três primeiras em destaque são as mais popularmente utilizadas.

 

- ADO.NET Typed Datasets : Ferramenta nativa do ADO.NET desde a versão 1.1, porém só a partir da versão 2.0 do framework que veio com os TableAdapters, que permitem o mapeamento entre Métodos e Comandos SQL. (http://msdn.microsoft.com/en-us/library/esbykkzb.aspx)

 

- NHibernate : Uma ferramenta de mapeamento objeto relacional para .NET. Com ela você faz o mapeamento em arquivos XML, e todos os comandos SQL são gerados em tempo de execução. É compatível com a grande maioria de databases relacionais existentes no mercado. (http://www.hibernate.org/343.html)

 

- ADO.NET Entity Framework  : Mais nova ferramenta da Microsoft destinada ao mapeamento objeto/relacional. Introduz o conceito de Entidades, e é compatível com vários databases. Gera os comandos SQL em tempo de execução e é totalmente compatível com a linguagem LINQ para a construção de queries. (http://msdn.microsoft.com/en-us/library/bb399572.aspx)

 

- SubSonic : (http://subsonicproject.com/)

 

- LLBLGen Pro : (http://www.llblgen.com/defaultgeneric.aspx)

 

- DataObjects.NET : (http://www.x-tensive.com/Products/DO/)

 

- Data Tier Modeler for .NET (DTM) : (http://www.evaluant.com/web/fr/DesktopDefault.aspx)

(http://devintelligence.com/blogs/netadventures/archive/2005/04/18/560.aspx) 

 

- eXpress Persistent Objects for .NET : (http://www.devexpress.com/Help/?document=Xpo/CustomDocument1998.htm&levelup=true)

 

- Eldorado.NET : (http://eldorado-net.sourceforge.net/)

 

- Entity Broker : (http://www.powernodes.com/cms.ashx/product/technical-information/entity-broker.html)

 

- JC O/R Framework & AtomsFramework : (http://sourceforge.net/projects/jcframework/)

 

- Nolics.NET :  (http://www.nolics.net/Main.aspx?topic=default)

 

- Norpheme :  (http://www.norpheme.com/ )

 

- ObjectBroker : (http://sourceforge.net/projects/objectbroker/)

 

- ObjectSpark : (http://www.firestarsoftware.com/products/objectspark.asp)

 

- Objectz.NET : (http://howtoselectguides.com/products/objectzdotnet/v2.2)

 

- DomainObjects for .NET (antigo OJB.NET) : (http://portuguese.osstrans.net/software/ojb-net.html)

 

- OPF.NET : (http://www.chilisoftware.net/OPFNET/)

 

- ORM.NET : (http://orm-net.sourceforge.net/)

 

- Genome : (http://www.genom-e.com/)

 

Note que estas são apenas algumas ferramentas com este propósito. Se você pesquisar mais a fundo, certamente irá encontrar muitas outras.

 

É importante entender o motivo pelo qual essas ferramentas existem. O problema todo é que passamos a desenvolver as nossas aplicações com a Orientação a Objetos, e a Orientação a Objetos não se dá lá muito bem com os bancos de dados relacionais.

Uma classe não é igual a uma tabela; um objeto não é igual a um registro; associação não é chave estrangeira; um banco de dados relacional não suporta herança; e estas coisas que já estamos cansados de ouvir.

Mas por que será que se criam tantas ferramentas para resolver o mesmo problema? Alguns acreditam que isso ocorre porque até agora o problema não foi solucionado de forma definitiva. Por isso essa incansável busca atrás da ferramenta perfeita.

Perfeccionismos a parte, muitas dessas ferramentas fazem o trabalho de forma muito eficiente e produtiva, mas acabam abrindo mão da compatibilidade e padrões da Orientação a Objetos. Já as que são fiéis à OO, se mostram ferramentas menos produtivas e também menos performáticas.

Mas a razão pela qual eu acredito que até agora ainda se lança ferramentas deste tipo, é que nenhuma delas consegue simplificar o processo de armazenamento e recuperação de dados, como deveria ser, ou como era em tempos saudosos de CLIPPER e COBOL.

Numa outra vertente existem os Bancos de Dados Orientados a Objetos, ou ODBMS (Object Data Base Management System – Sistema de Gerenciamento de Banco de Dados de Objetos), que ao invés de tentar unir o mundo da orientação a objetos com o mundo dos bancos de dados relacionais, oferece uma solução de armazenamento Orientada a Objetos.

O DB4Objects é uma solução deste tipo, que tem uma versão compatível com o .NET Framework. Além dele, existe uma série de outros databases orientados a objetos, a grande maioria ainda voltada para a plataforma Java, mas temos algumas boas opções para .NET, veja uma lista dos principais ODBMS:

· Caché (http://www.intersystems.com/cache/index.html)

· Cerebrum : Object-oriented network knowledge base (http://www.codeplex.com/Cerebrum)

· ConceptBase (http://www-i5.informatik.rwth-aachen.de/CBdoc/index.html)

· Bamboo.Prevalence (http://bbooprevalence.sourceforge.net/)

· DB4Objects (http://www.db4o.com/)

· eXtremeDB (http://www.mcobject.com/extremedbfamily.shtml)

· Generic Object Oriented Database System (GOODS) (http://www.ispras.ru/~knizhnik/goods.html)

· JADE (http://www.jadeworld.com/jade/)

· JDOInstruments (http://www.jdoinstruments.org/)

· JODB (Java Objects Database) (http://www.java-objects-database.com/)

· Magma Object Database (http://wiki.squeak.org/squeak/2665)

· MyOODB (http://www.myoodb.org/)

· ODABA (http://run-software.com/inhalt/products/odaba/)

· ObjectDB (http://www.objectdb.com/)

· Objectivity/DB (http://www.objectivity.com/)

· ObjectStore (http://www.progress.com/objectstore/index.ssp)

· Orient ODBMS (software) (http://www.orientechnologies.com/cms/)

· Ozone Database Project (http://www.ozone-db.org/frames/home/what.html)

· Perst (http://www.mcobject.com/perst)

· Prevayler (http://www.prevayler.org)

· Versant Object Database (http://www.versant.com/)

· Zope Object Database (http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html)

· XPrevail (http://xprevail.sourceforge.net/)

                  

Criar uma aplicação que armazena dados em um database orientado a objetos é ridiculamente simples. É como se não estivéssemos armazenando os dados em lugar algum no disco, a impressão é que a memória RAM utilizada pela aplicação ficou lá preservada, mesmo depois que desligamos o computador.

Isso é facilmente observado, pois toda aquela parafernália que temos em ambientes, onde há o Mapeamento Objeto/Relacional, vai embora. Ou seja, com um ODBMS você não precisa mais daquelas diversas camadas que os seus dados percorrem para conseguir transformar um simples objeto que está na memória, em um registro no banco de dados. Adeus ao “Pavê de Código”.

Não que o desenvolvimento em camadas seja algo ruim, longe disso. Mas que ele seja usado para o bem da reutilização de código, e não apenas como “tradutor de objetos/dados relacionais”.

Em contrapartida, um banco de dados orientado a objetos vai trazer outros problemas que não tínhamos antes, o principal é a falta de compatibilidade e aderência do mercado para databases deste tipo.

É realmente difícil convencer uma empresa a utilizar um banco de dados orientado a objetos. A confiabilidade e segurança que os bancos de dados relacionais ganharam no decorrer dos anos é bastante sólida e significativa. Tanto que é muito comum ter como pré-requisito de projetos, o uso de um ou outro banco de dados relacional.

Mas deixemos essas questões de lado por enquanto. Vamos ver na prática como utilizar o DB4Objects, ou para simplificar: db4o.

 

Conhecendo, Baixando e Instalando o db4o

O db4o surgiu inicialmente para Java, mas como toda ferramenta que é boa pra Java, logo ganhou uma versão para .NET Framework. A grande característica do db4o é a sua facilidade. Como veremos só precisamos de uma única DLL, e através do nosso próprio código conseguimos criar e configurar nossos databases, para serem utilizados em aplicações Windows Forms, ASP.NET ou Compact Framework.

Você também não precisa instalar o db4o nas suas distribuições, basta enviar junto com a sua aplicação esta mesma DLL. Mas isso não quer dizer que você não consegue criar aplicações Client/Server com ele. O db40 dá suporte para o modelo cliente/servidor, mas de uma forma muito mais simples do que a tradicional.

O db4o é completamente transacional e permite a execução de queries de diversas formas possíveis, sendo inclusive compatível com o LINQ, como veremos a seguir. Ele também suporta ambientes de replicação, onde você precisa manter bancos de dados off-line.

Há uma grande preocupação quanto a performance quando falamos de bancos de dados orientados a objetos. O db4o preza por uma boa performance, dê só uma olhada neste benchmark aqui: http://www.db4o.com/about/productinformation/benchmarks/.

...

Quer ler esse conteúdo completo? Tenha acesso completo