Artigo .net Magazine 61 - DB4Objects

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista .NET Magazine - Edição 61.

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

 

imagem_pdf.jpg

 

DB4Objects

Banco de Dados Orientado a Objetos para .NET

 

Vivemos tempos contraditórios no mercado de desenvolvimento de software, principalmente no quesito avanço tecnológico. Enquanto algumas áreas avançam a galope, outras parecem estar andando em círculos.

Veja o caso do ADO.NET por exemplo. Desde o seu surgimento foram incontáveis as ferramentas, frameworks e padrões que surgiram com o objetivo de armazenar/recuperar dados de uma aplicação orientada a objetos em databases relacionais, como SQL Server, Oracle, Postgre, MySQL, etc.

Só para citar algumas ferramentas que de um jeito ou de outro tentam resolver esta questão no .NET, temos: os Typed Datasets (nativo do ADO.NET), NHibernate, LLBLGen Pro, XPO (eXpress Persistent Objects da DevExpress), DataObjects.NET, SubSonic, e os mais recentes lançamentos da Microsoft: LINQ to SQL e ADO.NET Entity Framework.

Como dizem os franceses, C´est tout la meme chose! Todas essas ferramentas, desde as mais antigas até as mais recentes, têm o mesmo propósito: fazer a interface entre aplicações orientadas a objetos com bancos de dados relacionais. E essa é só uma pequena amostra, dê uma olhada na nota do DevMan uma lista bem maior de ferramentas com este mesmo propósito.

                 

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.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?