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.