Entity Framework 4 vs NHibernate [fechado]


114

Muito se tem falado sobre a primeira versão do Entity Framework na web (também sobre stackoverflow) e é claro que não foi uma boa escolha quando já temos uma alternativa melhor como o NHibernate. Mas não consigo encontrar uma boa comparação entre Entity Framework 4 e NHibernate. Podemos dizer que hoje o NHibernate é o líder entre todos os .NET ORMs, mas podemos esperar que o Entity Framework 4 desloque o NHibernate dessa posição. Acho que se a Microsoft realmente injetou recursos muito bons no EF4, pode ser uma boa competição para o NHibernate, pois tem integração com o Visual Studio, é mais fácil de trabalhar e sempre é dada preferência aos produtos MS na maioria das lojas.


31
Eu gostaria de uma atualização dessa comparação. Muito aconteceu desde '09?
Phil,

Respostas:


66

EF4 tem uma resposta out-the-box no que diz respeito ao desenvolvimento n-tier, em "entidades de auto-rastreamento". Ninguém lançou um código comparável para NHib.

O NHib tem muitos recursos que não foram mencionados como parte do EF4. Isso inclui a integração do cache de segundo nível. Ele também tem maior flexibilidade no mapeamento de herança, melhor integração com procs armazenados / funções de banco de dados / SQL / gatilhos personalizados, suporte para propriedades de fórmula e assim por diante. IMO é basicamente apenas mais maduro como um ORM.


13
+1 Você está certo. NH está apenas maduro. EF vai se recuperar até o final do ano. A versão 4.0 já fez uma entrada dramática. Espere um pouco e será à prova de balas em meados de 2011.

15
-1 Para "EF4 tem uma resposta out-the-box com relação ao desenvolvimento de n camadas, em" entidades de auto-rastreamento ". Ninguém lançou um código comparável para NHib." Existe ISession.Merge em NHibernate, que é muito melhor do que entidades Self-Tracking para desenvolvimento de N-Tier por muitos motivos.
Alex Burtsev

12
@Alex - De que forma o NHibernate é uma solução "pronta para usar"? Só para esclarecer; "Fora da caixa" significa que funciona com uma instalação simples do Visual Studio. Isso é um -1 injustificado ali mesmo.
Doctor Jones

9
@DoctaJonez - Do jeito que eu li, Alex estava contestando a ideia de que o NH não tem nada comparável a entidades de auto-rastreamento, não a parte sobre ser "pronto para usar".
Jerph

2
Na verdade, descobri que o EF4 tem um mapeamento de herança mais flexível. Por exemplo, você pode usar 2 tabelas (TPT) como classe base + classe de nível 1 e adicionar discriminador à tabela de nível 1, permitindo a divisão para classes de nível 2. Em NH, o discriminador só pode ser definido na classe base.
Danny Varod

37

Atualização: Eu não uso o Entity Framework desde a versão 4.0, então minha resposta pode estar desatualizada. Ainda estou usando NH ou ADO .NET puro em meus projetos. E eu nem quero ver o que há de novo na EF desde 4.0, porque o NH funciona perfeitamente.

Na verdade, é muito fácil compará-los quando você usa os dois. Existem algumas limitações sérias com EF4, posso citar algumas que encontrei por mim mesmo:

Problemas EF4:

  • Eager Loading e moldar o resultado : o sistema EF4 de carregamento antecipado (Include ("Path")) gera SQL impróprio, com JOINs em loop, que executará milhares (não literalmente) de tempo mais lento para relacionamentos muitos-para-muitos do que SQL escrito à mão (é efetivamente inutilizável).
  • O materializador não pode materializar entidades associadas : se você pode pensar que pode superar o problema anterior fornecendo sua própria consulta SQL, você está errado. EF4 não pode materializar (mapear) entidades associadas a partir da consulta SQL JOIN, ele só pode carregar dados de uma tabela (então se você tiver Order.Product, SELECT * FROM order LEFT JOIN O produto inicializará apenas o objeto Order, o produto permanecerá nulo, pensei que todos os dados necessários são obtidos na consulta para iniciá-lo). Isso pode ser superado usando o complemento da comunidade EFExtensions, mas o código que você terá que escrever para isso é muito feio (eu tentei).
  • Entidades de auto-rastreamento: Muitos dizem que entidades de auto-rastreamento são legais para o desenvolvimento de N camadas, incluindo a resposta principal neste tópico. Pensei que não tivesse nem tentado, posso dizer que não. Cada entrada pode ser forjada, você não pode simplesmente pegar as alterações que o usuário envia a você e aplicá-las ao banco de dados, por que não fornecer dados diretos ao usuário acesso à base então? De qualquer maneira você terá que carregar os dados que o usuário está prestes a mudar do banco de dados, verifique se ele existe | não existe, verifique as permissões etc. etc. Você não pode confiar no usuário no estado da entidade que ele está enviando para o servidor tem que carregar esta entidade do banco de dados e determinar seu estado e outras coisas, portanto, essas informações são inúteis, assim como entidades de auto-rastreamento, a menos que você faça um sistema privado de n camadas para uso interno, caso em que talvez você possa fornecer apenas Acesso ao banco de dados.

  • Log, eventos, integração de lógica de negócios: EF4 é como uma caixa preta, ele faz algo e você não tem ideia do que ele faz. Há apenas um evento OnSavingChanges onde você pode colocar alguma lógica de negócios que você precisa para executar antes que algo aconteça com o DB, e se você precisar aplicar algumas alterações aos objetos de negócios antes que algo aconteça, você terá que cavar em ObjectStateManager, e isso é realmente feio , o código pode se tornar enorme. Se você, por exemplo, estiver usando o padrão de repositório e o que deve ser notificado sobre as alterações feitas no banco de dados de forma limpa de objetos, você terá dificuldade em fazer isso com EF.

  • Extensibilidade: Todo o código EF é privado e interno, se você não gosta de alguma coisa (e você não vai gostar MUITO se levar a sério o uso de EF), de jeito nenhum você vai mudar isso de maneira fácil, na verdade, tenho certeza é mais fácil escrever seu próprio ORM do zero (eu fiz) do que fazer o EF trabalhar conforme você precisa. Como exemplo, dê uma olhada no código-fonte do EFExtensions, ele é baseado em métodos de extensões e diferentes "hacks" para tornar o EF um pouco mais usável, e o código é muito feio (e não é culpa do autor, quando tudo no EF é privado, este é o único forma de estendê-lo).

Posso continuar a escrever coisas ruins sobre a EF e como foi doloroso para mim trabalhar com ela por cerca de 20 páginas, e talvez o faça.

E o NHibernate? É um nível absolutamente diferente, é como comparar PHP com C #, EF4 é como na Idade da Pedra, é como se EF estivesse 10 anos atrasado em relação ao NHibernate em progresso de desenvolvimento, e de fato está, o Hibernate foi iniciado em 2001. Se você tiver tempo livre para aprender e ligar o Nhibernate, faça.


1
EF foi lançado sob a licença Apache 2, que deve ajudar com extensibilidade.
CMircea 01 de

@MirceaChirea Isso, ótima notícia, eu não esperava isso, navegando no código-fonte da EF agora, uma leitura bem interessante.
Alex Burtsev

2
-1 por fazer várias declarações precedidas de "Não usei isso, mas estou falando mesmo assim."
Kyeotic

@Tyrsius Minha resposta foi escrita, quase 3 anos atrás, eu não uso EF há muito tempo, algumas coisas poderiam melhorar, você pode editar minha resposta para atualizar para o status EF atual.
Alex Burtsev

2
Você admite que nunca usou entidades de auto-rastreamento, mas ainda assim as dispensa. Que tal falar apenas com o que você sabe e deixar de fora as suposições ignorantes, especialmente porque o parágrafo inteiro está muito errado.
Tom Halladay

25

Aqui está a coisa. NHibernate e Entity Framework são realmente para dois públicos diferentes, na minha opinião. NHibernate seria minha escolha em construir um sistema com mapeamentos, fórmulas e restrições complexas (basicamente qualquer coisa corporativa). Se eu quisesse executar com sucesso simples acesso a dados, usaria Entity Framework ou LINQ-to-SQL. O NHibernate não tem uma experiência clara de "arrastar e soltar" como o EF. Ambos têm seus pontos fortes e desvantagens. Compará-los maçãs com maçãs, francamente, não leva a lugar nenhum.


13
Você já experimentou o ActiveWriter? O Entity Framework é absolutamente voltado para o espaço empresarial. Eu discordo da maioria do que você disse.
Michael Maddox

1
Discorde o quanto quiser, mas o fato de o NHibernate existir há mais tempo é algo que as empresas NÃO esquecem.
zowens

21
-1 Esta não é uma boa comparação de NHibernate vs. Entity Framework. Comparar os dois combinando EF com LINQ to SQL apenas b / c ele tem arrastar e soltar é hipócrita, na melhor das hipóteses. No que diz respeito à complexidade, o que exatamente o NHibernate pode fazer e o EF 4 não?
Kevin Babcock

14
Cache de segundo nível, suas consultas são ALTAMENTE otimizadas, o NH força você a usar o padrão UnitOfWork, além de que os mapeamentos não são comprimidos em um arquivo. Minha opinião (por experiência) é que o NHibernate tem mais desempenho. Discordo de mim nisso, mas eu disse que era minha opinião. Meu ponto em minha resposta AINDA é válido, ambos têm seus pontos fortes e fracos. Ninguém pode negar isso.
zowens

2
@ MakerOfThings7 isso é patético ... toda essa questão é subjetiva. Acorde ...
zowens

23

Se você acha que pode querer executar seu código no Mono, NHibernate é provavelmente a melhor escolha, não importa o que as listas de verificação de recursos digam ...

Editar, 13/08/2012:

O Entity Framework foi de código aberto e agora está incluído no Mono a partir de 2.11.3. Esta resposta agora está desatualizada e não deve ser considerada.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx


De fato, em mono-project.com/Compatibility ele lê "EntityFrameworks - Not available." E parece que ninguém está interessado em implementá-lo. Então, pelo menos por alguns anos, é NHibernate ou nada.
user276648

12

Minha opinião sobre isso é que EF4.0 percorreu um longo caminho desde 1.0 e está alcançando o Nhibernate em funcionalidade, mas ainda não está tudo lá.

No entanto, é Microsoft, pronto para usar, e faz 100% do que 95% dos aplicativos precisam que ele faça. No entanto, o NHibernate tem feito a mesma coisa há anos. Venha a versão 5.0 ou 6.0 pode alcançá-la, ou até mesmo ultrapassar o NHibernate.

Aqui está o meu conselho - se você tem tempo para aprender os dois, faça-o. Existem várias razões para escolher um em vez do outro. Se você está escrevendo um código para uma empresa, é realista esperar funcionários que estejam familiarizados com a EF, pois está em todos os livros e no que as crianças aprendem na faculdade. Se a EF atenderá às suas necessidades (pense nisso por muito tempo antes de dizer sim), então é uma solução perfeitamente adequada por enquanto, e em alguns anos pode (ok, provavelmente irá) ultrapassar o NHibernate.

NHibernate é um produto muito maduro com alguns anos de EF e provavelmente fará tudo o que você gostaria de fazer e muito mais. Já faz algum tempo que é o melhor ORM e muitas pessoas o usam.


10

Acho que o fato de que EF 4 terá a capacidade de usar POCO e carregamento lento adiado será muito grande. Eu definitivamente pude ver isso ganhando força com o novo lançamento.


7
Não se esqueça do suporte LINQ. O NHibernate ainda não é bom nisso.
Arnis Lapsa,

1
@Arnis, você pode fornecer algum link para apoiar essa opinião?
Michael Maddox

2
@Michael, isso fica aparente quando você olha as postagens do blog de Ayande sobre o assunto. LINQ to NH é baseado na API de critérios no momento. A API de critérios não permite algumas das funções de consulta mais complexas que o HQL permite. A próxima versão do LINQ to NH usará HQL em vez da API de critérios.
zowens

5

Há uma tendência óbvia de aumento da popularidade do EF em relação ao NHibernate, veja a foto.

NHibernate vs Entity Framework



Que de acordo com a tendência, as pessoas estão começando a usar o Google EntityFramework mais com o tempo. E eles podem ter um bom motivo para isso. Talvez tenha começado a melhorar.
Tomas Kubes de

Pode ser esse o caso, pode também ser o caso de ser o que está a ser sugerido por defeito para ser utilizado pela MS. Além disso, o ferramental para EF é muito bom.
Răzvan Flavius ​​Panda de

4

Meus 2 centavos: usamos ef em nosso cliente de desktop para algumas cahing etc - sem cargas hi. Um NHib no lado do servidor - utilizando sessões sem estado, geração de hilo id e lotes. É bastante rápido em inserir 3k + mensagens em db por segundo. Além disso, é muito flexível e suporta muitos dbs, o que é crucial para o nosso produto.


3

Mapear diretamente para procedimentos armazenados com uma combinação de Linq para uma camada lógica parece a abordagem mais fácil. Sem xml. Gere sql apenas para consultas interessantes que são usadas com menos frequência ou não adequadas para procedimentos armazenados.

Os objetos são carregados e armazenados por meio de SPs padrão. Essa abordagem permite o uso de dois logins sql. Um para o acesso à classe através de SPs (permissões somente de execução) e um para um módulo lógico linq que permite acesso direto à tabela.


1

Escolher entre ORMs por popularidade não é a melhor coisa a se fazer. Eu tentei mudar para a EF nos últimos 2 anos e tudo que posso dizer é, por que diabos eu ainda tento?

ATM meu ponto de vista sobre o EF é: "Ele é feito para sistemas de bits muito pequenos realmente pequenos, com não mais do que 3 tabelas com menos de 1 relacionamento (0 é melhor)".

E por que eu penso assim? 1. Tente atualizar um gráfico desconectado e veja o zero do seu modelo;

  1. Tente fazer TPH com árvores herdadas profundas e você descobrirá que está preso a uma única hierarquia ou o sistema irá quebrar.

  2. Tente fazer consultas mais complicadas e observe todo o sistema devorando a pilha: D ... os overflows acontecem com frequência.

  3. Os tipos de dados Map XML são baseados em extensões ou nas propriedades NotMapped mais "odiadas" ... e é ainda pior.

  4. Tente misturar a consulta SQL no Linq para consultas mais refinadas e você quebrará a parede lol.

  5. E a última e mais importante coisa, EF não oferece suporte à fórmula de propriedade ('um recurso incrível que o NH tem para bancos de dados legados') e não oferece suporte a mapeamentos de tipos complexos para a mesma tabela e tabelas relacionadas.

Essa é a minha 10cc.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.