Object Relational Mapping Tutorial: Principais conceitos dos ORMs

Fique por dentro

A grande maioria dos softwares desenvolvidos precisa persistir dados em algum lugar e em grande parte das vezes estas dados s�o persistidos em bases de dados relacionais, que ainda s�o absolutas no mercado, diante disso, o tema deste artigo � �til para qualquer aplicaç�o que tenha estas caracter�sticas,possibilitando o aumento da produtividade e facilitaç�o do desenvolvimento das mesmas, al�m de nivelar e padronizar a camada de acesso a dados do sistema.

O que � ORM?

ORM ou Object Relational Mapping � uma t�cnica de mapeamento objeto relacional que visa criar uma camada de mapeamento entre nosso modelo de objetos (aplicaç�o) e nosso modelo relacional (banco de dados) de forma a abstrair o acesso ao mesmo.

Com isso, ao longo do tempo foram criados diversos frameworks ORM, que nos ajudam nas tarefas de persist�ncia e recuperaç�o de dados, nos dando mais produtividade em nossas tarefas di�rias. Neste artigo veremos os conceitos principais por tr�s da t�cnica e dos frameworks ORMs, como a sua mec�nica e funcionamento. Veremos o que s�o e como trabalham, conceituando as principais caracter�sticas destes e apresentando quais os principais frameworks existentes no mercado.

Quase todo sistema precisa gravar dados durante seu uso que podem ser guardados para posterior processamento ou leitura como, por exemplo, num sistema de uma loja que precisa guardar os dados dos produtos, vendas, funcion�rios, dentre outros.

No mundo .NET temos um caminho padr�o para acessar dados em SGDBs relacionais atrav�s do ADO.NET, biblioteca que nos fornece diversas classes para acesso e manipulaç�o de dados, n�o somente de SGDBs relacionais como tamb�m de XMLs e documentos do Office (como excel e access).

Por outro lado, ao adotar uma soluç�o baseada puramente em ADO.NET sofremos com alguns problemas, como por exemplo:

Temos que escrever todo o SQL de nossa aplicaç�o manualmente, tornando o desenvolvimento do projeto muito mais improdutivo.
Temos que nos preocupar em n�o usar nenhum c�digo SQL espec�fico de determinado SGDB para n�o corrermos o risco de ficarmos preso ao mesmo.
Temos mais classes para gerenciar e dar manutenç�o.

Saiba mais: Guia Completo de SQL

Al�m disso, o modelo de dados relacional possui algumas limitaç�es em comparaç�o com o modelo de objetos (Nota do DevMan 1), como por exemplo:

N�o possui herança
N�o possui polimorfismo
N�o permite relaç�es N para N entre duas entidades (tabelas)

Nota: Chamamos de modelo de objetos toda a modelagem do dom�nio de nossa aplicaç�o, onde temos nossas classes com seus respectivos m�todos e atributos, al�m dos relacionamentos entre as mesmas.

Diante disto, corremos o risco de limitar a arquitetura de nossa aplicaç�o orientada a objetos ao modelo relacional. Para resolvermos este problema precisamos realizar um parse dos dados de um modelo para o outro. Este parse pode ser feito manualmente, atrav�s de consultas SQL acessando as tabelas de nosso banco de dados e alimentando objetos de nossa aplicaç�o, ou de forma autom�tica utilizando uma camada de mapeamento, chamada ORM, como ilustrado na Figura 1.

Figura 1. Ilustraç�o do mapeamento

ORM (Object Relational Mapping) � uma t�cnica para mapeamento entre um modelo de dados relacional e um modelo orientado a objetos que visa resolver, ou pelo menos minimizar, as diferenças entres estes dois modelos. Para facilitar a aplicaç�o desta t�cnica surgiram os frameworks ORM, como por exemplo, o NHibernate e o Entity Framework. Desta forma, esses frameworks se localizam em uma camada intermedi�ria entre a l�gica da sua aplicaç�o e o seu SGDB.

O framework passa a receber as solicitaç�es de interaç�o com o SGDB atrav�s de objetos de sua aplicaç�o e gera automaticamente todo o SQL necess�rio para a operaç�o solicitada, nos poupando do trabalho de escrita e manutenç�o deste SQL e abstraindo o uso do SGDB, fazendo com que nos preocupemos apenas com nosso modelo de objetos. Al�m disso, o framework j� trata as variaç�es de tipos de dados existentes entre nossa aplicaç�o e nosso SGDB.

Com isso, nossa aplicaç�o passa a interagir com o framework e n�o mais com a base de dados diretamente, desacoplando nosso sistema de SGDBs espec�ficos. Al�m disso, com uso de frameworks ORM a produtividade aumenta devido ao fato de n�o precisarmos escrever c�digos SQL para inserir, alterar, excluir e recuperar dados do SGDB.

Os Principais ORMs

Os principais ORMs que trabalham com o .NET s�o o Entity Framework e NHibernate mas estes n�o s�o os �nicos. A primeira tentativa de ORM da Microsoft no .NET foi o LinqToSQL, que ainda � usado por muita pessoas mas que aos poucos foi sendo substitu�do pelo Entity Framework. Na vers�o 4 do .NET a Microsoft anunciou que iria descontinuar o LinqToSql, tornando o Entity Framework a opç�o nativa para ORM.

O Entity Framework vem ganhando melhorias muito rapidamente, no momento em que escrevo este artigo a vers�o 6 j� est� dispon�vel em alpha e a opç�o da Microsoft por torn�-lo Open Source aumentou o ritmo de melhorias e sugest�es ao framework.

Por�m, o NHibernate ainda possui uma consideravel prefer�ncia por possuir uma comunidade ativa e por suportar mais escolhas de bancos de dados do que o Entity. A conversa sobre performace pode ser esquecida a partir da vers�o 5 do Entity Framework quando a performace se equiparou entre eles.

Al�m desses dois h� v�rios outros ORMs, como por exemplo podemos citar:

SubSonic, que pode ser o terceiro framework mais famoso e usado, com uma comunidade ativa, gratuito, com suporte a c�digos gerados com T4 Templates e suporte a querys feitas usando LINQ.
Telerik ORM � a opç�o paga que promete muito suporte, com a promessa da facilidade (com Drag and Drop) e alta taxa de melhora de produtividade.

MicroORMs

At� agora conversamos sobre ORMs comuns, mas tamb�m temos a nossa disposiç�o os chamados MicroORMs que s�o mais simples, muitas vezes somente um arquivo ou dll a ser acrescentado no projeto, que possuem poucas funcionalidades e somente o mapeamento b�sico.

� comum um MicroORM se vangloriar de ser mais r�pido e perform�tico do que um ORM completo. A justificativa est� na sua simplicidade e o modo direto, sem intermedi�rios, de acesso ao SGDB relacional.

Dois exemplos de MicroORMs seriam o Drapper e o PetaPoco. O Drapper � adicionado ao projeto com somente um arquivo e possui 3 helpers. J� o PetaPoco trabalha com v�rios tipos de SGDBs, com geraç�o de c�digo com T4 Templates e possui mais helpers do que o Drapper.

A adoç�o de microORMs costuma ser em projetos muito simples ou que precisam de uma performace que n�o foi atingida com um ORM mais complexo.

Como funciona o ORM?

O ORM funciona atrav�s do mapeamento das caracter�sticas da base de dados para os objetos de nossa aplicaç�o. O primeiro conceito chave � traçar um paralelo entre Classe x Tabela e Propriedade x Coluna. O ORM nos permite informar em que tabela cada classe ser� persistida e em que coluna do SGDB cada propriedade ficar� armazenada, como podemos observar na Figura 2.

Figura 2. Ilustraç�o do de uma classe para uma tabela

Na ilustraç�o da Figura 2 n�s temos uma tabela cliente na base de dados e uma classe cliente em nossa aplicaç�o com as setas indicando o mapeamento da classe da aplicaç�o para a tabela da base de dados. Este mapeamento considera coisas como o nome da coluna, o tipo da mesma, tamanho e precis�o, dentre outras caracter�sticas. Um exemplo de mapeamento, em XML, pode ser visto na Listagem 1.


   <?xml version="1.0" encoding="utf-8" ?>
   <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" 
     namespace="DevMedia.Exemplo " assembly="DevMedia.Exemplo">
     <class name="DevMedia.Exemplo.Cliente, 
     DevMedia.Exemplo" table="TB_CLIENTE">
       <id name="Codigo" column="CodCliente"/>
       <property name="Nome"/>
       <property name="CPF"/>   
     </class>
   </hibernate-mapping>

Listagem 1. Exemplo de mapeamento em XML com NHibernate

Na Listagem 1 podemos observar um exemplo de mapeamento atrav�s do framework NHibernate. Veja que na linha 2 n�s definimos o namespace e o assembly onde est� a nossa classe e na linha 3 n�s indicamos o nome da mesma seguido do nome de sua respectiva tabela no banco de dados. Na linha 4 temos uma tag Id que indica que o campo Codigo da classe � o identificador do objeto, mapeando o mesmo para a coluna CodCliente que � a chave prim�ria da tabela. Por fim, nas linhas 5 e 6 temos o mapeamento das propriedades da classe Cliente. Vale ressaltar que nestes casos n�o foi informado o nome da coluna no banco de dados, pois as colunas possuem o mesmo nome das propriedades do objeto Cliente.

Com todo este mapeamento realizado, o framework passa a ter todas as informaç�es necess�rias para recuperar e persistir objetos na base de dados.

Al�m disso, acima foi demonstrado um exemplo de mapeamento via arquivo XML externo, atrav�s do NHibernate, por�m existem outros tipos de mapeamento normalmente disponibilizados pelos frameworks ORM, sendo eles:

Usando atributos customizados em nossas classes
Usando Fluent API

O mapeamento por XML, exemplificado na Listagem 1, � um dos mais comuns e est� presente em muitos ORMs, como por exemplo, no pr�prio NHibernate. Um inconveniente deste mapeamento � a quantidade de XMLs gerados, al�m da manutenç�o um pouco mais trabalhosa, uma vez que voc� ter� que faz�-la em arquivos XMLs, sem os recursos de refatoraç�o e Intellisense nativos do Visual Studio.

O outro tipo de mapeamento � atrav�s de anotaç�es, onde n�s definimos no c�digo do modelo as caracter�sticas da tabela ou coluna representada por cada classe e atributo. Em .NET temos os Custom Attributes que s�o utilizados entre colchetes, sendo aplicados �s classes e propriedades, para realizaç�o do mapeamento. Um exemplo de mapeamento usando anotaç�es pode ser visto na Listagem 2.


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using NHibernate.Mapping.Attributes;
  
  namespace DevMedia.Exemplo
  {      
         [Class(Table = "TB_CLIENTE")]
         public class Cliente
         {
          [Id(Column = "CodCLiente")]
          public Double Codigo { get; set; }

          [Property]
          public Double Nome { get; set; }
  
          [Property]
          public Double CPF { get; set; }
         }
  }

Listagem 2. Exemplo de mapeamento com anotaç�es com Hibernate

Como podemos ver no exemplo da Listagem 2, na linha 9 n�s temos a definiç�o do atributo Class com o par�metro Table indicando o nome da tabela onde esta classe est� mapeada, enquanto que na linha 12 n�s temos a indicaç�o de que a propriedade Codigo � o identificador do objeto e est� mapeada para a coluna CodCliente da base de dados. Por fim temos o mapeamento das outras propriedades nas linhas 15 e 18.

O que muitos consideram como um inconveniente das anotaç�es � que a classe que usa muitos Custom Attributes fica polu�da e, caso o framework ORM fosse trocado,ter�amos que alterar todas as nossas classes para que usassem os atributos do respectivo framework.

Como alternativa ao mapeamento, temos ainda normalmente o uso de uma Fluent API, que trata-se de uma API de mapeamento que implementa o pattern Fluent Interface (Nota do DevMan 2). Um exemplo deste tipo de mapeamento pode ser visto na Listagem 3.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using FluentNHibernate.Mapping;
using DevMedia.Exemplo.ExemploHeranca; 

namespace DevMedia.Exemplo
{
       public class ClienetMap:ClassMap<Cliente>
       {
        public ClienetMap() {
            Id(x => x.Codigo).Column("CodCliente");
            Map(x => x.Nome);
            Map(x => x.CPF);

            Table("TB_CLIENTE");
        }
      }
}

Listagem 3. Exemplo de mapeamento com Fluent API em NHibernate

Nota: Fluent Interface � um pattern que prev� a criaç�o de uma API com um c�digo mais leg�vel, permitindo que o c�digo seja escrito de maneira mais fluente.

Na Listagem 3 podemos observar o mapeamento com o FluentNHibernate, que � uma iniciativa da comunidade que visa permitir o mapeamento usando uma Fluent API para o NHibernate. Veja que nossa classe de mapeamento herda de uma classe base de mapeamento do FluentNHibernate, chamada ClassMap (linha 10), indicando no tipo gen�rico a classe que queremos mapear. Esta classe � a respons�vel por determinar o mapeamento de um objeto do sistema para a base de dados.Na linha 13 temos um m�todo que nos permite indicar a propriedade identificadora do objeto e a coluna para onde a mesma est� mapeada. Nas linhas 14 e 15 n�s temos o mapeamento das propriedades Nome e CPF, n�o sendo necess�ria a definiç�o da coluna da base de dados, pois esta possui o mesmo nome das propriedades do objeto. Por fim, na linha 17 temos a definiç�o da tabela onde os dados da classe Cliente ser�o persistidos.

Para muitos o uso de Fluent Interface � o melhor dos dois mundos, onde podemos realizar todo o mapeamento em arquivos separados utilizando o pr�prio C#, com todos os recursos de refatoraç�o e intellisense dispon�veis e sem poluir nossos objetos.

Persist�ncia de Dados

Muito bem, agora que j� compreendemos como as tabelas e colunas s�o mapeadas para classes e propriedades, como � feita a persist�ncia destes dados atrav�s de frameworks ORM?

Cada ORM tem seu estilo de c�digo para a persist�ncia dos dados, mas em geral eles possuem o mesmo caminho: interpretar o comando que voc� solicitou, verificar qual funç�o ou conjunto de funç�es SQL s�o necess�rias para executar o comando solicitado, efetuar a leitura do mapeamento da classe que voc� est� usando, gerar o SQL necess�rio, abrir uma conex�o com o SGDB, executar o SQL e retornar o resultado.

A seguir temos dois exemplos bem diferentes, um em ruby com o ActiveRecord, um ORM muito popular dentro do framework Rails, e um exemplo em C# com o Entity Framework.


pessoa = Pessoa.new
pessoa.nome = "Priscila Mayumi Sato" 
pessoa.save

Listagem 4. Exemplo de comando para salvar com ActiveRecord


using (CFcontext db = new CFcontext())
  {
    Pessoa pessoa = new Pessoa();
    pessoa.Nome = "Priscila Mayumi Sato";
    db.Pessoas.Add(pessoa);
    db.SaveChanges();
  }

Listagem 5. Exemplo de comando para salvar com Entity Framework

Podemos notar diferentes formas de persistir os dados. Na Listagem 4 temos o exemplo com ActiveRecord: podemos ver que foi instanciado um objeto do tipo Pessoa, foi atribuido um valor para o atributo Nome e depois o pr�prio objeto pessoa se persistiu no banco de dados com o m�todo save.

Na Listagem 5, em C# com Entity Framework, temos a declaraç�o de um contexto de persist�ncia de dados (objeto db), instanciando um objeto do tipo Pessoa, atribuindo um valor a propriedade Nome e posteriormente adicionando este objeto pessoa a um container (Pessoas) de seu tipo, e ap�s isso o objeto foi persistido usando o m�todo SaveChanges do contexto de persist�ncia.

Os m�todos Save e SaveChanges possuem o mesmo objetivo: persistir mudanças de objetos da mem�ria para o banco de dados, por�m foram disponibilizados de formas diferentes, uma sendo chamada diretamente no objeto mapeado e o outro solicitando que o objeto a ser persistido seja adicionado a um container.

No momento em que estes m�todos foram acionados, o framework ORM verificou o mapeamento das classes para identificar qual o nome da tabela respons�vel e das respectivas colunas do banco de dados e gerou um SQL dinamicamente, semelhante c�digo abaixo, e executou o mesmo no SGDB em quest�o.


INSERT
INTO TB_PESSOA(NOME) VALUES ("Priscila Mayumi Sato";);

Formas de acesso aos dados

Os frameworks ORM nos fornecem uma s�rie de maneiras para acessar os dados persistidos no nosso SGDB, dentre estas formas podemos destacar:

OCL � Object Constraint Language � S�o consultas baseadas em crit�rios definidos em objetos, como por exemplo, os objetos Criteria do NHibernate.
SQL � S�o consultas baseadas em um SQL tradicional. Neste caso normalmente � passado o c�digo SQL para o framework e o mesmo retorna uma lista de objetos com o resultado da consulta.
Linguagens espec�ficas � Consultas baseadas em linguagens espec�ficas do framework ORM em quest�o, ou seja, ao inv�s de usar SQL utilizamos uma linguagem espec�fica que o pr�prio framework suporta, como por exemplo, o Linq no caso do Entity Framework.

Al�m disso, cada framework possui caracter�sticas e recursos adicionais, como por exemplo, o NHibernate que possui um recurso chamado Named Queries que nos permite armazenar consultas SQL (ou tamb�m HQLs) em arquivos xml separados e depois mapeie os mesmos, como mapeou suas tabelas, podendo assim us�-las a qualquer momento no seu c�digo.

Na Listagem 6 podemos ver um exemplo de query SQL sendo executada atrav�s do Entity Framework:

 
 using (CFcontext db = new CFcontext())
 {
       string nativeSQLQuery = "SELECT count(*) FROM dbo.Edicoes"
       var queryResult = db.ExecuteStoreQuery<int>(nativeSQLQuery);
       int totalEdicoes = queryResult.FirstOrDefault();
 }

Listagem 6. Exemplo de uso de querys SQL no Entity Framework

N�o � uma regra mas n�o � incomum encontrar uma linguagem pr�pria de consulta nos frameworks ORM (Exemplo HQL / Linq). A mec�nica � que os comandos na linguagem espec�fica passem por um interpretador da framework e depois sejam traduzidos para uma query SQL para ser executada no SGDB.

Normalmente essas linguagens de consulta s�o parecidas com a linguagem SQL. Exemplos de linguagens de consulta s�o o LINQ do .NET, o HQL do NHibernate, a DQL (Doctrine Query Language) do Doctrine (framework de ORM para linguagem PHP), e a LIQUidFORM, uma linguagem que se inspirou no LINQ s� que para rodar no JPA (Java Persistence API) da plataforma Java.

A mec�nica � semelhante ao passar um comando do framework para que ele interprete e crie os comandos SQL, a diferença � a flexibilidade, pois com uma linguagem pr�pria de consultas, temos mais liberdade para trabalhar com os dados. Al�m disso, voc� n�o precisa se preocupar com o uso de comandos espec�ficos de cada SGDB, pois a pr�pria framework j� trata isso.


IEnumerable<Student> studentQuery =
    from student in students
    where student.Scores[0] > 90
    select student;

Listagem 7. Exemplo de comando com LINQ

Na Listagem 7 podemos observar que temos uma estrutura que vai receber o resultado da query. Podemos perceber que a query inicia de forma contr�ria ao SQL, com um comando from, mostrando de onde ser�o retirados os dados, para depois ser inserida a condiç�o where e por fim o select. Essa estrutura � tida como mais l�gica e nela � suportado o intellisense (auto-complete do visual studio).


ISession sessao = sessionFactory.OpenSession();
  ICriteria criteria = sessao.CreateCriteria<Cliente>().
Add(Expression.Eq("Sexo", "Masculino"));
  IList<Cliente> clientes = criteria.List<Cliente>();

Listagem 8. Exemplo de consulta utilizando Criteria

Na Listagem 8 temos um exemplo que demonstra uma consulta utilizando os objetos de criteria do NHibernate onde adicionamos uma nova express�o de consulta de igualdade, recuperando todos os clientes do sexo masculino. Ao executar o m�todo criteria.List o NHibernate gera internamente todo o SQL necess�rio para recuperaç�o do resultado.

Performace

Um fator muito importante ao escolher um ORM para seu projeto � estudar a performace do mesmo. Um framework ORM lida diretamente com o banco de dados e isso implica em leitura e escrita em disco, que representa um recurso caro, por isso um ORM que faz consultas e gravaç�es de dados de forma desorganizada pode acabar sendo menos eficiente.

Outro fator que impacta na performace � o cache das consultas. Deixar algumas consultas em mem�ria pode fazer com que voc� ganhe alguns milesegundos. Outro cache poss�vel e importante � o de resultados das consultas que s�o feitas com maior frequ�ncia.

Uma discuss�o recorrente � se a adoç�o de ORMs n�o diminui a performace do sistema que o adota. Realmente a performace pode cair, pois voc� est� adicionando camadas adicionais e mais processamento no caminho entre a l�gica da aplicaç�o e os dados. Mas se o ORM for bom, seu modelo for coeso e estiver bem mapeado, a pequena queda de performace provavelmente n�o ser� percebida pelos usu�rios finais, sendo notada somente em testes espec�ficos, visto que a diferença estar� na casa de mil�simos de segundos.

Mesmo que voc� perca alguns mil�simos de segundos, a adoç�o vale a pena por aumentar consideravelmente a produtividade da equipe.

O que vale ressaltar � que se voc� est� trabalhando com um grande volume de dados, por exemplo um relat�rio que retorna dezenas de milhares de registros ou uma importaç�o de um grande volume de registros, pode ser melhor executar isso com SQL nativo do que com um framework ORM, visto que se formos criar dezenas de milhares de objetos em mem�ria para isso, a diferença de performance poder� sair da casa de mil�simos de segundos e passar� para a casa de segundos (ou at� minutos, dependendo do volume de dados), sendo percebida pelo usu�rio final. Al�m disso, aplicaç�es cr�ticas onde estes mil�simos de segundos fazem diferença para o dom�nio em quest�o n�o devem usar ORM, buscando sempre o acesso mais direto poss�vel � informaç�o.

Diante dos principais pr�s (produtividade e manutenç�o) e contras (performance), o que vale � sempre o bom senso para avaliar cada caso, sempre buscando o melhor equil�brio, avaliando o que � mais importante e o que traz mais impacto para o projeto em quest�o.

Conclus�o

Como vimos neste artigo o uso de frameworks de ORM auxiliam no desenvolvimento de aplicaç�es tornando mais f�cil o manejo de dados bases de dados relacionais. Apesar de trazer facilidades nem sempre poderemos utilizar somente ORM, por isso � necess�rio aprender tamb�m a sintaxe SQL. Um relat�rio complexo � um exemplo em que normalmente a melhor forma de se fazer � com SQL nativo.

Como muitos frameworks ORM trazem alguns recursos espec�ficos, tamb�m � bom estudar e se aprofundar no framework que voc� for usar para que se possa tirar o melhor proveito do mesmo. Nem sempre voc� usar� o mesmo framework que est� acostumado, por isso preste atenç�o nos frameworks que forem surgindo no mercado e na comunidade.

Vale ressaltar ainda que o foco deste artigo foi apresentar o conceito ORM e algumas das caracter�sticas chaves, sem entrar em muitos detalhes de implementaç�o, servindo como base para as pr�ximas ediç�es onde falaremos mais sobre o Entity Framework e o NHibernate, apresentando exemplos pr�ticos completos sobre os mesmos.

Links:

ORM - Object Relational Mapping - Revista Easy .Net Magazine 28

Neste artigo veremos os conceitos principais por trás da técnica e dos frameworks ORMs, como a sua mecânica e funcionamento.