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.


ORM


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 (9)
  1. werhmuller says:

    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.

  2. Daniel Wander says:

    Vejo que o uso do EF tem sido o mesmo que eu empregava para os Typed DataSet. Cria-se visões ou agrupamentos (EDMX), o que se fazia o mesmo com os XSDs.

    Vejo uma única vantagem, em termos de ORM, é que agora temos uma forma correta de modelar os sistemas, ou seja, criar primeiro o modelo de classes e depois o banco. E com os Typed DataSets isso não era possível; ao menos de uma maneira prática.

    Outro ponto interessante para o EF, é a possibilidade de criarmos o mesmo conceito de "contratos" para uma camada BLL se comunicar com essa DAL baseada em EF. Creio que isso talvez gere um pouco de independência tecnológica e nos permita maior flexibilidade em mudanças de tecnologias futuras.

  3. Otavio says:

    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.

  4. Daniel Wander says:

    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.

  5. Otavio says:

    Concordo plenamente, Daniel.

  6. fiorentin0 says:

    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".

  7. werhmuller says:

    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.

  8. 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!

  9. Otavio says:

    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

Comments are closed.

Skip to main content