|
Do que se trata o artigo? |
|
Neste artigo conheceremos o DB4Objects, um banco de dados orientado a objetos originalmente para Java, mas que também tem sua versão para .NET |
|
Para que serve? |
|
O DB4Objects é um banco de dados, e como tal tem o propósito de armazenar os dados de uma aplicação. O grande diferencial dele frente aos bancos de dados mais conhecidos do mercado é o fato de armazenar os dados na forma de objetos, e não em estruturas relacionais. |
|
Em que situação o tema é útil? |
|
Um banco de dados orientado a objetos, como é o caso do DB4Objects, pode facilitar e agilizar o desenvolvimento de uma aplicação orientada a objetos, já que com ele não precisamos nos preocupar com a “transformação” dos objetos da aplicação em dados relacionais, e vice-versa. |
Resumo do DevMan
Veja neste artigo como utilizar o DB4Object, um excelente banco dados orientado a objetos. E conheça os benefícios e obstáculos que temos ao optar por uma ferramenta como esta.
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 cria tanta ferramenta 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 à 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 na nota do DevMan.
Nota do DevMan
Veja uma lista de alguns Bancos de Dados Orientados a Objetos e Frameworks de prevalencia de objetos, que temos hoje disponíveis no mercado:
- 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)
...
