Entity Framework e ORM's em geral

Estudando e procurando referências sobre o Entity Framework (EF) é fácil encontrar boas discussões sobre seu uso e arquitetura. Nestes momentos, aproveito sempre para generalizar estas discussões para um contexto maior - a classe de produtos ORM’s em geral - uma vez que a crítica é sempre uma comparação com um modelo ideal de ORM. Mas será que existe um?

Uma crítica que li refere-se ao EF não ser uma camada ORM independente e multi-plataforma para ser utilizado por todos os softwares da empresa – o objeto de desejo de um Enterprise Architect. Lembro-me que já existia em 98 produtos nesta categoria de ORM – com cachê de objetos para serem compartilhados por múltiplas aplicações (ver figura abaixo). Na época eu trabalhava numa empresa de ERP e meu medo era um simples VBScript vindo de uma planilha atualizando meu banco de dados sem que o cachê do ORM soubesse. Bem, com certeza, o EF não se coloca nesta categoria. Ele é simplesmente uma tecnologia de acesso a dados através de objetos.

Outra discussão interessante: devemos fazer um DAO acima do EF? A pergunta tem sentido se considerarmos que novas tecnologias de acesso a dados devem chegar num futuro ainda próximo e que esta talvez nos obrigue a mudar de tecnologia de acesso a dados ou de ORM dos nossos futuros legados. A contrapartida é que este excesso de camadas e sobre-engenharia, além de ter um custo alto para o desempenho, talvez tenha um custo de implementação maior do que o simples refactoring futuro da aplicação. Sinto um cheiro de excesso aqui. Mas já existem até livros sobre este assunto usando o EF, como o Pro Linq Object Relational Mapping.

Por fim, existe a crítica de que o EF não é Persistence Ignorant (PI). Isto é, o EF não permite (ao que parece, ainda, já que existe a promessa de torná-lo PI numa versão futura) que o programador crie uma classe comum e a mapeie contra o banco de dados. No EF, ele deve seguir as regras, herdando de classes e interfaces por exigência do Framework. Por que isto é ruim? Além de contribuir com a PI, ORM’s com esta qualidade facilitam o teste das regras de negócio antes que os dados existam em um repositório, o que é essencial quando usamos o TDD (Test Driven Design). O lado bom costuma ser o desempenho e alta integração com frameworks existentes – como a integração com o Linq e interfaces de bind do .Net Framework.

Tenho cada vez mais pensado e utilizado o EF como um mero acesso a dados. Faço queries Linq nas regras de negócio e trabalho com um ou mais ObjectContext (uma espécie de DataSet que armazena os objetos retornados pelas queries) por thread/transação. Crio diferentes edmx para cada visão ou agrupamento de tabelas segundo o domínio de negócio e uso o System.Transaction para garantir as propriedades ACID nas transações que usam mais de um ObjectContext. Simples, com desempenho aceitável e de alta produtividade. O que de fato espero de um ORM.

Comments

• Anonymous
  August 04, 2008
  também tenho utilizado como uma maneira simples de acesso à dados. Tenho utilizado uma camada acima(DAO) e o custo disso pareceu razoável até então. No futuro pretendo excluir esta camada e trabalhar diretamente com o EF e LINQ.

• Anonymous
  August 04, 2008
  The comment has been removed

• Anonymous
  August 04, 2008
  Daniel, Creio que três são os pontos fortes do EF:

1. Trabalho com Orientação a Objetos, transformando resultados de queries em objetos em memória e navegando através deles sem esforço;
2. Ele cria uma camada conceitual acima da camada física, possibilitando mudanças (como denormalização) no físico com pouco impacto no conceitual e, por sua vez, no programado;
3. Uso do Linq quando necessário; Do meu ponto de vista, todos estas funcionalidades estão um ou mais níveis acima do que acontecia no Typed DataSet. Creio que vale a pena testar por você mesmo. Abraços.

• Anonymous
  August 04, 2008
  Concordo... já estive dando uma olhada no EF. O que eu queria destacar é a real capacidade ORM do EF, diante de soluções como o nHibernate; e até em relação ao Linq To SQL, que não nos fornece o conceito completo de ORM. Creio que seja uma migração natural para o EF todos que usam o Typed DataSet; mas agora, podemos criar uma BLL baseada em contratos para isolarmos a tecnologia e termos aplicações com melhor escalabilidade.

• Anonymous
  August 04, 2008
  Concordo plenamente, Daniel.

• Anonymous
  August 04, 2008
  Ainda não baixei o EF. Ja usei o NHibernate. Há algum tempo venho usando o CastleProject. MonoRail + Windsor e, em outro projeto, MonoRail + Windsor + NHibernate. Estes frameworks combinados com alguns Design Patterns são poderosos. Se a MS decidiu reiventar a roda, poderiam fazer algo igual ou melhor... que façam "wizards" no Visual Studio para tornar o processo mais produtivo, para quem quiser ou puder pagar o preço dos atalhos, dependendo do projeto, mas sem comprometer a arquitetura e flexibilidade da ferramenta para quando houver necessidade. Classes e interfaces obrigatórias que poderiam ser substituídas por metadados não me agradam. Não ajudam a praticar - "Separation Of Concerns".

• Anonymous
  August 05, 2008
  outro ponto prático do EF é a "aceitação" fácil e simples da modelagem de Banco de Dados. Em algumas empresas, como é o meu caso aqui, a modelagem de dados é feita por uma área de DBA´s, onde esse pessoal está preocupado com as informações em si, pois são elas muito mais importantes do que qualquer objeto ou classe. E neste caso, os DBA´s utilizam as velhas técnicas de modelagem, o que era muito penoso "mapear" para objetos. Fiz alguns testes e pude comprovar o poder do EF.

• Anonymous
  August 05, 2008
  Olá Otávio, Não acredito que o EF esteja preparado, neste momento, para atender todas as demandas que o desenvolvimento de um software corporativo complexo traz. Você listou os problemas, não vou fazê-lo novamente. Acho que o que mais pega realmente é separação de responsabilidade e testabilidade. O que eu espero de um ORM é que ele me dê a possibilidade de criar objetos de negócio, e que ele faça no final a serialização para a base de dados. Só isso. Dessa forma, posso testar meus objetos e ter toda a liberdade na montagem da arquitetura da solução. O EF traz mais do que isso, ele me liga à base de dados. Dependendo como for estruturada a chamada, quem acaba disparando a consulta é a camada de aplicação, o que está totalmente fora do SRP. No entanto, para aplicativos mais simples, ele ajuda muito, isso é inegável. E vem com um editor visual, o que falta em grande parte das ferramentas ORM de sucesso no mercado, seguindo uma abordagem que a Microsoft sempre vem usando. Enfim, tem seus prós e seus contras, como tudo na vida. Acredito, no entanto, que a Microsoft, já que se dispôs a fazer um ORM, poderia ter dado a outra opção, que contemplasse as necessidades que você falou, eu falei, e a comunidade toda está falando. Quem sabe, como você disse, em uma próxima versão. Um abraço!

• Anonymous
  August 05, 2008
  Boa discussão, Giggio. Estou pensando em um entrada no blog só para discutir alguns dos assuntos que você mencionou. O grupo de produtos do EF fez algumas escolhas visando um mercado de aplicações. Vou tentar em breve falar sobre o onde colocar queries linqs e tentar te demonstrar que, com uso adequado, mantemos o Separation of Concerns num nível adequado. Vamos ver se consigo... Abraços