NHibernate vs Entity Framework - Revista .Net Magazine 101

Nos dias atuais, a grande maioria das aplicações que desenvolvemos faz operações com bancos de dados, sendo na maioria das vezes utilizado um banco de dados relacional. Por outro lado, nos últimos anos temos visto uma crescente busca pelo aumento da produtividade nas empresas de software, principalmente com a popularização cada vez maior do paradigma orientado a objetos, com todo seu apelo ao reuso e desacoplamento.

Isto nos leva a um problema de diferença entre paradigmas. Temos nossas aplicações com uma modelagem mais próxima ao modelo de negócio de nossos clientes, porém temos bases de dados relacionais que armazenam nossos dados com uma estrutura diferente. Além disso, cada SGDB possui um dialeto diferente, fazendo com que corramos o risco de deixar nossa aplicação “presa” a determinados SGDBs.

Esta diferença de modelos foi uma das principais motivações, aliada à produtividade e abstração dos SGDBs, para a criação dos frameworks de mapeamento-objeto-relacional(ORM), porém isso só foi possível devido à toda evolução na arquitetura das plataformas e à criação de padrões e APIs como o ODBC.

API ODBC

O ODBC é uma API escrita em C para o acesso a dados em SGDBs que foi criada para funcionar com qualquer sistema operacional e qualquer banco de dados que possua um driver que implemente as interfaces ODBC. Para seu pleno funcionamento foi criada uma padronização específica da linguagem SQL que funcionasse independentemente de banco de dados.

O grande entrave do ODBC reside na dificuldade de configuração e na necessidade de alto conhecimento técnico dos profissionais que programam aplicações de acesso a dados. Com o intuito de melhorar as interfaces ODBC, em meados de 1994 a Microsoft criou as bases para o padrão OLE DB.

Como sucessor do ODBC o OLE DB provê uma série de interfaces com a utilização de objetos COM funcionando de forma distribuída. Diferentemente do ODBC, com o OLE DB é possível acessar uma grande variedade de fontes de dados de maneira uniforme permitindo o acesso a bases de dados não relacionais, bancos de objetos e planilhas.

A intenção inicial deste padrão era a portabilidade das aplicações, porém isso só era possível em ambiente Microsoft. Com o intuito de facilitar ainda mais a abstração da forma como as aplicações acessam seus dados, a Microsoft criou um conjunto de interfaces de acesso a dados, englobando objetos de conexão, gerenciadores de sessão, adaptadores de dados, objetos de comando e objetos transacionais.

Não muito diferente dos provedores ODBC e OLE DB, a utilização do .NET Data Provider depende da implementação das suas interfaces para o acesso a SGDBs.

Os .NET Data Providers do SQL Server já acompanham por padrão o .NET Framework, facilitando assim o desenvolvimento de aplicações que acessem este SGDB. Para os demais SGDB’s é necessário que as interfaces do .NET Data Provider sejam implementadas em uma biblioteca distribuída. Seguem alguns exemplos de SGDBs e seus respectivos provedores de dados:

PostgreSQL - Npgsql Data Provider

Oracle Oracle - Data Provider

FireBird - Firebird .NET Provider

MySQL - MySQL Connector .NET

NHibernate – Um pouco de história

Não obstante ao projeto Hibernate, Tom Barrett com o apoio de diversos desenvolvedores .NET, iniciou em meados de 2004 um projeto sinônimo ao Hibernate, batizado NHibernate. Em 2005 o projeto passou a ser liderado por Sergey Koshcheyev, ante a JBoss Inc. Um ano depois o projeto deixou de ser suportado pela JBoss passando a ser fomentado exclusivamente pela comunidade NHibernate Forge, sob a liderança de Fabio Maulo.

Hoje o NHibernate já contém uma forte bagagem de ferramentas provendo segurança e confiabilidade no desenvolvimento de aplicações de acesso a dados na plataforma .NET.

Entity Framework – Um pouco de história

Em paralelo ao NHibernate a Microsoft lançou, em conjunto com o Visual Studio 2008 SP1,o .NET Framework 3.5 e o então chamado Entity Framework (EF) 1.0. Dentre os principais recursos apresentados, o Entity Framework promovia o desenvolvimento de aplicações com base na tecnologia Linq, o que foi um grande diferencial entre as ferramentas ORM.

Mesmo em meio às críticas dos desenvolvedores, o projeto EF 1.0 evoluiu com a chegada do .NET Framework 4, passando a ser chamado de EF 4, apesar de ser a segunda versão.

O grande salto do EF em relação a outras ferramentas ORM foi a total integração com o Visual Studio, permitindo ao desenvolvedor a criação de modelos de entidades relacionais de forma visual.

Mesmo com esse grande avanço, o framework permanecia bastante engessado e atrelado às versões anteriores do Visual Studio, dificultando a migração de aplicações para as novas versões. Isso sem mencionar a falta de suporte a classes CLR planas tradicionais, os chamados POCOs.

Visando a solução deste problema, a Microsoft lançou mão do padrão de desenvolvimento chamado Code First que, além de introduzir o suporte a POCOs, trouxe novos recursos como o suporte a carregamento de objetos sob demanda (lazy loading), suporte a aplicações N-Tier, dentre outros.

NHibernate, Entity Framework, Incompatibilidades e Provedores de dados

Apesar dos provedores OLE DB e ODBC do .NET implementarem as interfaces do ADO.NET, o Entity Framework 4 é incompatível com ambas as tecnologias, deste modo, bancos que possuem apenas drivers OLE DB e ODBC não poderão ser acessados via Entity.

Em contrapartida, o NHibernate utiliza as interfaces do ADO.NET, permitindo o suporte a uma gama maior de fontes de dados, incluindo ODBC e OLE DB. Isto é possível por conta da interface IDriver. Esta interface é utilizada internamente pelo NHibernate para a obtenção de objetos de conexão e comandos de bancos de dados, devendo ser implementada pelo NHibernate Driver (Nota do DevMan 1) do banco de dados a ser utilizado.

O NHibernate contém suporte nativo a inúmeros SGDBs, porém caso um determinado banco não seja previamente suportado basta que seja implementada esta interface para o banco em questão e o NHibernate irá se conectar ao mesmo.

A Tabela 1 lista os principais SGDBs e se os mesmos são suportados pelo NHibernate e Entity Framework.

...