NHibernate x Entity Framework

[Michel Henrique Aquino Santos]

Bom dia pessoal.

Estou começando um projeto e por falta de experiência, não sei qual framework de persistência de dados utilizar, NHibernate ou Entity Framework.

O que recomendam? 

Quais são os pontos fortes e fracos de cada um?

Abraços

--

Att,

Michel Henrique Aquino Santos
Bacharel em Ciência da Computação
Universidade Federal de Lavras - UFLA
Gtalk: miche...@gmail.com

Skype: michel_has

http://resolvidoslinux.blogspot.com/

[Penihel Roosewelt]

Usa o Entity Framework. é o default Microsoft. Resolve em todos os casos, e facilita a manutenção futura.

em .Net todo mundo tem obrigação de saber o EF, o NHibernate é mais periférico (somente alguns usam)

Agora os dois resolvem!

[Márcio Fábio Althmann]

Que problema quer resolver?

Digo isso porque talvez algo assim pode ser um exagero, já usei sem problema micro orm's em alguns projetos, por exemplo o ORM Lite do  ServiceStack ou o Dapper.

2013/5/15 Michel Henrique Aquino Santos <miche...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[daniel carli]

Penihel,

Não concordo com sua afirmação, sobre só alguns usarem o NHiberbante, ele está a muito mais tempo presente e sendo usado na comunidade do que o Entity Framework.

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Daniel Carli

dcrlz.tumblr.com

[Marcus Alexandre Silva]

[2] 

"NHibernate Periférico" não corresponde a verdade. 

Os caras estão ai desde 2005 (acho) e já vinha de boa bagagem herdada do Hibernate do Java.

[Priscila Mayumi Sato]

Apesar de adorar EF eu concordo com o Daniel, NH ainda é mais usado.

E um micro ORM pode ser útil...

você pediu lista de pontos fortes e fracos, mas... depende. 

A verdade é que eu acho EF Code First muito mais organizado #prontoFalei

{parando por aqui para não ser tendenciosa }

Em 15 de maio de 2013 14:21, daniel carli <dansa...@gmail.com> escreveu:

--

Priscila Mayumi Sato

Twitter: @MayogaX

[Michel Henrique Aquino Santos]

Eu tive uma pequena experiência com o NHibernate e funcionava muito bem. Pensei em usar ele pelo motivo que o Daniel falou, por estar mais tempo presente, além de ser Open Sourse e não depender da boa vontade da Microsoft em atualizar e melhorar as funcionalidades.

Em 15 de maio de 2013 14:21, daniel carli <dansa...@gmail.com> escreveu:

[Marcelo Acioli Bastos]

Seguindo os conselhos do Roosevelt, use o Entity Framework. Porque?

Minha experiencia com o Nhibernate não foi muito boa, talvez porque no projeto que atuei algumas particularidades podem ter atrapalhado, porém nós tivemos vários problemas com o NHibernate. Quebramos muito a cabeça com algumas coisas que no proprio Entity eram bem mais simples. Eu acho que para o JAVA o Hibernate funciona muitissimo bem, mas o Nhibernate ainda deixa a desejar no que diz respeito ao .net. Cara vai de Entity e pronto.

Em 15 de maio de 2013 14:18, Penihel Roosewelt <pen...@gmail.com> escreveu:

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Marcelo Bastos
Analista de sistemas
85-9997-3280
http://www.marceloaccioly.blogspot.com/

[Priscila Mayumi Sato]

Se for por ser Open ou não... EF também é faz uns meses...

[Márcio Fábio Althmann]

Se quer prós e contras ou uma comparação pode ver aqui alguma coisa http://www.infoq.com/news/2012/06/NHibernate-EF

Eu não usaria o EF, já me ferrei muito com ele! Mas novamente, veja o que precisa, que cenário precisa resolver/atender, cada framework resolve várias coisas de formas diferentes!!!

Pegue seus problemas e veja qual pode te ajudar mais com eles, não faça o contrário ;)

2013/5/15 Marcelo Acioli Bastos <bast...@gmail.com>

[Marcelo Acioli Bastos]

Lembro ainda que ao utilizar o NH utilizei o add-on FluentNHibernate. Bom, cada caso é um caso e é sempre bom voce verificar a sua necessidade, o que realmente voce precisa.

Marcelo

[daniel carli]

Cara essa questão sempre vai cair na máxima:

"Use o que sua equipe sentirá menos impacto".

você só vai começar a sentir diferença de um para outro quando você precisar implementar cache, customizar algum hook do framework e afins.

[Rafael De Souza]

Concordo com o Marcelo, use o FluentNHibernate, é fácil de aprender e de implementar padrões como unit of work e repository, vc poderá utilizar bancos como Mysql, Oracle, SQL Server ou até mesmo em memoria (bom para testes unitários)

Atenciosamente,
Rafael de Souza Conceição
(27) 9972-5638

[Felipe Zini]

Minhas experiências com o EF não foram bem sucedidas, acredito que um pouco por falta de experiência e por já estar acostumado ao NH.

Pelo menos a implementação de NH + Fluent + Repository funcionou bem mais tranquilo do que EF + Repository. Sempre tive problemas com mapeamento e updates de entidades (de novo, provavelmente por falta de conhecimento).

http://about.me/felipezini

[Marcelo Acioli Bastos]

Pois é o Fluent foi um facilitador. Em outro projeto com um amigo nos EUA usamos o Entity... gostei muito mais. Esta questão de ter tido problemas com o NH foi mais no inicio. Bom, de toda forma sou defensor de que seja verificado antes de mais nada afundo o seu projeto e sua necessidade, para não complicar o simples.

Marcelo

[David Anderson Lino de Sousa]

Eu gosto dos dois.

Se eu sei que vou usar o SqlServer, uso o EF sem pensar. Gosto muito e nunca tive problemas.

Mas se for usar algo como Oracle ou Postgres, vai de NH. Os drives para EF ainda são muito simples e problemáticos.

Att,
David 

[Marcelo Acioli Bastos]

Pois é David, o EF com Postgres e Oracle realmente apresenta algum probleminha, mas não são tão dificeis assim de contornar. O EF com SQL ai é um mundo quase perfeito...hehhehehee

[Marcelo Acioli Bastos]

O NH é muito utilizado, até mais do que imaginava. Um dos motivos que fora escolhido em um dos projetos que trabalhei foi justamente por este ser mais maduro até que o EF.

Marcelo

Em 15 de maio de 2013 14:21, daniel carli <dansa...@gmail.com> escreveu:

--

[Gustavo Moraes]

Aqui usamos NH.

1: Porque usamos Oracle e NH é muito mais maduro para Oracle

2: nos nossos testes de performance, os resultados foram melhores do que EF

Abs

Gustavo Moraes
Cel.: 21 8330 3131

[Priscila Mayumi Sato]

Realmente NH é mais performático que EF...até a versão 5 no .net 4.5

depois disso é sucesso :)

[Husseyn Hussa]

EF é pra quem não quer montar criteria e/ou não precisa de interceptors.

além de não ser o rei de abrangência para alguns cenários de mapeamento, como many-to-any, heranças e interfaces.

e NH é mais divertido, de fato.

[Marcelo Acioli Bastos]

Priscila voce fala que o EF é sucesso no .net 4.5? É isso?

Em 15 de maio de 2013 16:30, Priscila Mayumi Sato <mayum...@gmail.com> escreveu:

[Marcelo Acioli Bastos]

Concordo Husseyn, mas quando se usa o Fluent isso fica bem mais divertido e bem mais tranquilo. Quanto ao EF, lógico que ele nos da a oportunidade de ter mais facilidade....

Marcelo

[daniel carli]

o EF teve muitos ganhos de performance com seu update no framework 4.5.

[Priscila Mayumi Sato]

Desculpa, acabei falando de forma muito informal usando uma gíria aqui da região.

EF veio se tornando cada vez melhor desde a versão 4. A versão 5 é ainda mais performática, porém melhor ainda e batendo de frente com NH quando colocado no .net 4.5

Parte disso foi por causa da árvore de querys e uma nova estratégia de plano que querys.

[]s

[Ygor Thomaz]

EF

--
Ygor Thomaz
Website: http://www.ygorthomaz.com/ | Twitter: @ygorthomaz
"With Great Power Comes Great Responsibility." Uncle Ben, Spiderman


2013/5/15 Priscila Mayumi Sato <mayum...@gmail.com>:

[Michel Henrique Aquino Santos]

Obrigado pessoal... Vou considerar todas as opiniões e estudar qual seria a melhor ferramenta...

[Carlos Mendes]

O NH certamente é mais maduro, tem mais tempo de vida e já esta estável. O EF vem melhorando nos últimos releases, como já comentaram.

No NH existem diversos drivers maduros, pontos de extesão como interceptors e estrategias de cache. Com os interceptors, da pra fazer coisas bem divertidas para ganhar mais performance e alterar o comportamento do lazy load, por exemplo.

A resolução de problemas no NH é mais complexa, precisa de uma certa experiencia para garantir sucesso no uso.

O EF ainda esta crescendo e vem ganhando diversas funcionalidades e maturidade. Em breve pode se tornar uma ótima opção e deixar o NH pra tras.

Talvez o NH seja mais adequado para projetos maiores, mais robustos, que normalmente precisam de muitas customizações e "controle do que esta acontecendo" nas operações.

O EF é bem produtivo, uma das maiores vantagens, o que ainda lhe falta é a confiança (da maioria) na comunidade e grandes cases próximos da gente.

Micros ORM talvez seja uma boa opção para seu projeto, considere o uso.

--
Carlos Mendes

[Rafael Uchôa]

Carlos Mendes [+1]

Queria o bom dos dois mundos: Usar LINQ pra fazer consultas com o NH como implementação. Alguém tem bons cases e considerações de problemas usando essa abordagem ?

[Marcelo Acioli Bastos]

Rafael,

Usei o linq to NH em um projeto trabalhamos bem com ele e foi produtivo. usamos em um projeto grande e atendeu. Nossa equipe era bastante madura, mas não tivemos tantas dificuldades. Usamos o Linq to NH e os resultados foram legais.

Marcelo

[Gerson Dias]

Sempre usei o linq to nhibernate em meus projetos, e nas ultimas versoes ele faz parte do nh!

Enviado via iPhone

[Danimar Ribeiro]

Se for usar Nhibernate, recomendo não usar FluentNhibernate devido a questões de performance, utilize diretamente o mapeamento fluent do mesmo, ainda mais se tiver bastante entidades.

Nhibernate e EF >= 4.5 tem praticamente as mesmas características e funcionalidades, talvez implementadas de formas diferentes.

Eu até ariscaria dizer que EF>=4.5 está mais fácil e melhor de usar que o Nhibernate.

Apesar do Nhibernate ser mais velho, ele não tem uma boa documentação e isso conta bastante. Se for começar é melhor começar pelo EF pois a documentação da Microsoft sempre foi muito boa. (não estou falando de informações em fóruns)

Abraços.

[Leonardo Neubauer]

"Se for usar Nhibernate, recomendo não usar FluentNhibernate devido a questões de performance, utilize diretamente o mapeamento fluent do mesmo, ainda mais se tiver bastante entidades. "

qual motivo ? utilizo o FluentNhibernate e a perfomance é excelente.

[Priscila Mayumi Sato]

sim, são as mesmas funcionalidades no EF >= 4.5

mas é mais performatico, como eu disse antes, por causa, principalmente, da arvore de querys e plano de querys. É algo muito interno que fez a melhoria.

E, concordo, documentação é importante

Em 16 de maio de 2013 10:07, Danimar Ribeiro <danima...@gmail.com> escreveu:

[Felipe Oriani]

Bom, NHibernate já uso a alguns anos, sempre gostei. Fazer o mapping é chato mas importante saber o que faz.

O Linq dele vem sendo melhorado a cada nova versão mas também existe o QueryOver e o HQL. 

Já utilize com diversos bancos de dados (sql server, oracle, mysql e postgresql). 

Existe o NHProf para acompanhar a qualidade das queries geradas pelo ORM.

http://www.hibernatingrhinos.com/products/nhprof

O EF usei a versão 5 em um projeto com Sql Server (apesar de não ser um sistema com demanda de queries complexas), atendeu legal. Não sei a compatibilidade da última versão com outros bancos de dados.

Existem também a versão do EF (mas nunca usei)

http://www.hibernatingrhinos.com/products/EFProf

2013/5/16 Priscila Mayumi Sato <mayum...@gmail.com>

--

______________________________________
Felipe B Oriani

felipeoriani.com.br felipe...@gmail.com

[Rafael Uchôa]

É porque o FluentMapping gera em filesystem os hbm das classes, e assim fica mais lento durante a inicialização.

Uma solução é criar um parametro em tempo de desenvolvimento, para criar os hbm e deixar em um local específico, assim, esses hbm só precisam ser alterados se o modelo mudar, coisa que só acontece no início das sprints, o resto do tempo a gente não altera tanto o modelo, deixando esse parametro "false".

http://www.dotnetguy.co.uk/post/2009/10/19/using-fluent-nhibernate-to-export-create-hbm-files-nhibernate-mapping-files/

[Rafael Uchôa]

@Felipe,

QueryOver é bem interessante, tenho até uma pequena lib para fazer Specs com ele (https://www.nuget.org/packages/Naskar.QueryOverSpec/).

Mas com o poder, vem a complexidade. Nem todo mundo entende QueryOver, e assim o LINQ ficaria mais interessante pela simplificidade, então estou vendo as experiências de quem está usando essa abordagem.

Como o Carlos já falou, NH tem cache, tem interceptors, então falta só ser mais simples de fazer consultas com compile time check.

Quanto a documentação, é verdade, para .NET é meio complicado, mas acabo baixando o código e lendo direto na fonte.

[Luiz Carlos Faria]

Pois é, trabalhei em projetos grandes com FluentNHibernate e obtive sucesso na utilização do FluentNH. De fato, como dito aqui, a inicialização é penalizada, no entanto, os ganhos para o desenvolvimento são imensos e em conjunto com outras técnicas, torna esta estratégia matadora para garantir compatibilidade entre banco e aplicação.

[gabrie...@gmail.com]

Engraçado que ninguem aqui falou da funcionalidade do EF que eu considero o maior diferencial que tem dele hoje em dia que é o migrations. Com ele acho que o desenvolvimento fica muito mais "fluido". 
Ja trabalhei tanto com o EF quanto com o NH eu acho que o ef tem melhorado muito e tem muito a melhorar.
Quanto ao que falaram se olharmos o que for feito no NH nos ultimos anos e compararmos com o que foi feito no EF nos ultimos anos ta valendo muito mais depender da boa vontade da microsoft doq eu da boa vontade da "comunidade".

E a conexão com os outros bancos. quando eu comecei a usar o ef os providers para outros bancos eram muito ruins porem o trabalho que a devart (http://www.devart.com/) tem feito nos ultimos anos tem sido muito legal, inclusive a devart ja tem provider para oracle para o ef6 que nem saiu ainda....

Em 16 de maio de 2013 13:05, Luiz Carlos Faria <luizcar...@gmail.com> escreveu:

Pois é, trabalhei em projetos grandes com FluentNHibernate e obtive sucesso na utilização do FluentNH. De fato, como dito aqui, a inicialização é penalizada, no entanto, os ganhos para o desenvolvimento são imensos e em conjunto com outras técnicas, torna esta estratégia matadora para garantir compatibilidade entre banco e aplicação.

[daniel carli]

Existem migrations para o NHibernate tbm

--
Daniel Carli

dcrlz.tumblr.com

[gabrie...@gmail.com]

Sim existe para NH mas todas as vezes que eu tentei utilizar estava tipo longeeee de estar perto de algo que se possa usar em produção

[Marcius Oliveira]

Fala galera do DotNetArchitects, eu sou bem iniciante no mundo .NET, então não posso falar muito, mas tenho gostado bastante de trabalhar com o C#. 

Tive bastante contato com o Hibernate no Java, e posso garantir que é uma ótima ferramenta, a comunidade faz com que ela evolua rápido, e uma boa comunidade é uma peso a ser levado em consideração na hora de escolher suas ferramentas.  Mesmo tendo quase nenhuma experiência com .NET tenho tido péssimas experiências com ferramentas "corporativas", muitas vezes a opinião de uma empresa diverge muito das opiniões de quem usam suas ferramentas e essa divergência pode gerar perda de muito dinheiro com concertos emergências ou reescrita de todo um sistema por conta de mudança de visão da ferramenta que estava usando.

No entanto como disseram em um dos e-mails Entity passou a ser open-source, mas isso não é tudo, e a comunidade? é ativa? tem voz no produto final? essas coisas podem ser deixadas de lado no inicio mas são de extrema importância para produtos com vida longa.

Abraços.

Espero ter contribuído um pouco.

Marcius Oliveira Programador Pleno marcius.p...@gmail.com Tel: (21) 7148-7697

* Coding Dojo Rio *

dojo...@googlegroups.com

http://groups.google.com/group/dojo-rio

http://code.google.com/p/dojo-rio

http://dojorio.wordpress.com

[Priscila Mayumi Sato]

Considero que a resposta a suas perguntas é: SIM

[Denis Ferrari]

Escrevi um post sobre como eu decido entre uma ferramenta X ou Y (http://www.heroisdati.com/e-agora-qual-tecnologia-eu-uso/), mas falando especificamente do EF x NH tenho algumas considerações...

O que você vai fazer? Dependendo da forma como você expressa o seu domínio, talvez não haja grandes vantagens em nenhum dos dois frameworks. Todos esses ORMs atendem bem os cenários "básicos", principalmente se você quiser fazer CRUDs ou se seu modelo for anêmico.

Por exemplo, com modelagens ricas eu crio tipos personalizados nas minhas classes e ensino ao ORM como ele deve persistir esses tipos. Com o NH isso é tranquilo (é possível pelo menos), com o EF não era possível na primeira vez que eu tentei, hoje não sei como está. A questão é que nem todo projeto pede por isso. Se for ficar só no básico (e se for Sql Server), acredito que são equivalentes.

2013/5/16 gabrie...@gmail.com <gabrie...@gmail.com>

[Marcius Oliveira]

Valeu Denis, bem legal o post! Concordo que é necessário uma analise da real necessidade, você pode acabar economizando recursos onde achava que precisava.

[Denis Ferrari]

Só um adendo pessoal...

Eu NÃO disse que não é possível fazer domínios ricos no EF, disse que na primeira vez que tentei (na versão 4.1) eu não consegui usar um recurso específico, mas eles já devem ter melhorado essa parte. 

Ainda assim, fico impressionado como algumas coisas foram deixadas de lado na época, como o suporte a Enum que só veio na versão 5.

http://msdn.microsoft.com/en-us/data/jj574253.aspx

2013/5/16 Denis Ferrari <con...@denisferrari.com>

[Alexandre Santos Costa]

Estou usando ef em um modelo que tem crescido rapidamente nos mais diversos tipo de relacionamento e estou bem satisfeito

Enviado via iPhone

[Felipe Oriani]

@Rafael, realmente cara, eu também acabei usando o Linq em diversos pontos pois achei mais simples. Uma coisa que achei muito simples o QueryOver não suportar é a utilização de métodos primitivos em expressões, com linq por exemplo, eu consigo:

session.Query<Entity>().Where(x => x.Name.ToUpper() == "FELIPE").ToList();

Já com queryOver, a exception diz que não suporta o método ToUpper(). procurando solução ai vi o uso de projections e etc... desanimei, utilizei o Linq.

--------

Gosto muito de ferramentas ORM's, mas como diz um amigo meu DBA, 75% das pessoas que usam, não sabem o que estão fazendo!

2013/5/16 Rafael Uchôa <rafaeluc...@gmail.com>

--

[Daniel Rocha]

Olá Michel,

Pelo que li até agora, me permita algumas colocações:

“É Microsoft, tem que usar! Todo mundo tem que saber”. Então, vamos dar um exemplo: Boa sorte com o Unity e outras tecnologias superadas em performance, flexibilidade e robustez por muitas das várias opções de IoC Open Source à disposição no mundo .Net.

Me permitam repetir o óbvio, como diz Paulo Coelho: “A realidade é mais complexa do que gostaríamos que fosse (...)”. Qual o mais adequado ao seu projeto? Bem, aí vai um firme DEPENDE. O quão elaborado é o modelo que você desenvolveu para representar seu Domínio (seu negócio)? Se, na observação da complexidade do seu modelo, você vier a concluir que a ferramenta ORM deverá receber muitas “customizações” de seu comportamento padrão, a opção é o NHibernate. Ele tem mais extension points e opções para ajustar o comportamento a tarefas incomuns.

O Entity Framework me parece uma ferramenta concisa, e uniforme. Não sofre de certas incoerências observadas no NHibernate que são, em parte, cicatrizes devidas ao esforço de implementação partindo do original em Java. A esta qualidade do EF soma-se ao fato de este ser muito, mas muito melhor documentado que o NHibernate. Que os defensores do NHibernate me perdoem, mas especialmente quanto às features de versões mais recentes isto é mais verdade do que nunca. Começar com o NHibernate é pedra! Porém, pode ser recompensador no médio/longo prazo.

Se a operação em SGBDs diferentes está entre os requisitos de seu projeto, o NHibernate e, mais recentemente, o EF são escolhas equivalentes. Ambos trabalham com muito “dialetos” de vários bancos padrão no mercado. Uma ressalva: se você pender para a escolha do EF como seu ORM por ser esta uma tecnologia “legítima e pura” da Microsoft, lembre-se que a maioria dos muitos providers para SGBDS do EF não são desenvolvidos pela Microsoft, são de terceiros ou Open Source.

Quanto à estabilidade e performance, desisti desse debate faz quase dois anos, fiquem à vontade. Deixo apenas minha opinião: Pela minha experiência com NHibernate, configurado corretamente com seus recursos de cache e práticas performáticas (que lhe são permitidas dado à flexibilidade superior), é SIM mais rápido que EF. O que ninguém deve esperar neste tipo análise comparativa é grandes disparidades de resultado.

E segue o debate....

 

Daniel Rocha

[edmilson hora]

Gabriel, vou dar meus 2 cents  mesmo sem ter me aprofundado muito nos estudos  do migrations, em minha opinião o migrations ainda esta muito cru, existem outras alternativas gratuitas e muito mais simples que o migrations.

Utilizo uma ferramenta free  chamada Atlantis Schema Inspector, funciona perfeitamente para sicronizar esquemas e demais objetos de um banco para o outro,  então com ele vc pode ir crianado seu banco de desenvolvimento  sem se preocupar com o banco de produção e a qualquer momento vc pode atualizar o banco de produção de acordo com o de deselvolvimento.

[]´s

Edmilson

---

De: "gabrie...@gmail.com" <gabrie...@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Quinta-feira, 16 de Maio de 2013 13:50
Assunto: Re: [dotnetarchitects] Re: NHibernate x Entity Framework

[daniel carli]

o Juan fez um esquema de migrations que parece funcionar muito bem.

Daniel Carli

dcrlz.tumblr.com

[Juan Lopes]

2013/5/17 daniel carli <dansa...@gmail.com>:

> o Juan fez um esquema de migrations que parece funcionar muito bem.

Fiz, mas não trabalho mais com .NET. Por isso não toco no projeto há
quase dois anos.

https://github.com/juanplopes/pilgrim

[Marcos Tupan]

Trabalhei tanto com NH quanto EF, ambos são bacanas e acho interessante conhecer ambos. 

A diferença que percebi entre eles é que a curva de aprendizado do EF é menor, mas é claro que depende do banco que você vai utilizar e do que se deseja alcançar...

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--
Marcos Tupan
|41| 9147-8335

[Riderman]

Estou justamente migrando do EF para o NHibernate.

Trabalho com EF a muito tempo, tenho vários projetos desenvolvidos e já tive muitos problemas com EF principalmente utilizando FluentConfiguration. 

Na maioria das situações EF foi satisfatório, porém para este projeto (grande porte) os recursos do EF como Lazy Load (e outros) são limitados.

Pelo pouco que conheço do NHibernate (estou estudando :) ele supera em vários fatores o EF:

1. Performance:

http://gergelyorosz.com/2009/08/nhibernate-vs-entity-framework-a-performance-test/

2. Recursos:

http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx

3. Flexibilidade:

http://www.dennisdoomen.net/2013/03/entity-framework-56-vs-nhibernate-3.html

Porém confesso que a documentação para NHibernate deixa a desejar e a curva de aprendizado é bem maior!

Danimar Ribeiro, sua estratégia fui não usar FluentNHibernate? Preciso de performance na app que estou desenvolvendo. Interessante vc lenvantar isto.

Como resolveu as dependências? Estou apanhando com Ninject+NHibernate para deixar NHibernate apenas na camada de repositório! 

Michel Henrique Aquino Santos 

Seja qual for sua decisão.. repository pattern! :)

O Designer de sua app deve ser capaz de suportar qualquer ORM. Não sabemos o futuro e mudar ORM pode ser trabalhoso se o seu designer não for bacana. Sei por experiência!

Crie testes, após designer pronto modifique o ORM para conferir se está funcional, teste novamente!

[gabrie...@gmail.com]

@Riderman
Existem varios motivos que justifiquem a mudança do EF para o NH porem performace não é um deles. O uso de lazy load deveria ser muitooo bem avaliado por tanto em NH como no EF isto costuma a ser o seu maior vilão de performace.

quanto a essa parte de recursos muitos dos recursos que foram apontados existem maneiras de se trabalhar com algum deles.E muitos deles estão programados para sessoes futuras do EF como o ef 6 ou ja são suportados por exensoes.

[Riderman Sousa]

Sim, concordo. Em quesito performance ambos estão muito bem avaliados. A migração de EF para NH não é apenas por causa da performance!

Embora em larga escala, NH se mostra mais performático do que o EF (pelo menos pelo que li), mas a diferença é pouca!

Sobre o Lazy Load:

NHibernate suporta carregamento LazyLoad para:

• Entidades associadas (1-1, muitos para um);
• Coleções (um para muitos, muitos para muitos);
• Propriedades escalares (BLOBs ou CLOBs).

Entity Framework suporta LazyLoad para:

• Entidades associadas;
• Coleções.

Sobre recursos:

NH possui uma gama maior do que o EF como vários tipos de ID Generators e Events (mais de 20 incluindo instância de classes e geração de SQL), e outros nativo no NH que no EF não vem nativamente como Cache (second-level).

EF6

Pelo que li, virá com bastante novidades como Custom Code First Conventions, (algo que já existe no NH e é muito bacana!) entre outros. Porém a grande maioria o NH já suporta e no EF ainda está em alpha.

Testes

Este é quesito que deixo de lado pois não conheço muito bem da parte de testes do EF.

No NH existem helpers para testar os mapeamentos e testes de integração. Em resumo é bem tranquila! :)

Na minha modesta opinião, com qualquer um dos dois você estará bem servido, porém minha escolha vai para o NHibernate :).

[Felipe Santos]

Tenho projetos em NH de grande porte inclussive e ele atende perfeitamente, tanto no desenvolvimento quanto na parte atualização do banco de dados

Usei o EF (code first) uma vez e deixou muito a desejar em relação a atualização do banco quando o sistema já está em produção.

Resumindo por enquanto confio muito mais no NH

[gabrie...@gmail.com]

Entendo perfeitamente a sua escolha Riderman porem a longo prazo ainda prefiro o EF ainda mais quando vc pensa em um sistema que vai ter que ter um tempo de vidsa longo... Em termos de suporte não existe nenhum suporte para o nhibernate que eu considere descente assim como a documentação chega a ser piada. No EF caso vc tenha alguma duvida ou encontre algum bug no framework caso a sua empresa tenho uma assinatura msdn vc pode ter um suporte altemente qualificado ( falo porque ja tive a oportunidade de usar). 
No NH vc fica muito por conta propria caso encontre algum bug ou algum erro, e se olhar o ritimo de evolução dos dois verá que se existe alguma feature que o EF ainda esteja atrasado chances grandes que ele ja tenha ela daqui a 2 anos.... já o NH mesmo que tenha vc nao vai saber como ela foi implementada ou como utilizar pois isso não vai estar documentado em lugar nenhum....

--

[Mário Meyrelles]

+1 para o gabriel. 

2013/5/22 gabrie...@gmail.com <gabrie...@gmail.com>

[Rodrigo Silva de Andrade]

No meu caso eu prefiro o NH por pura necessidade, não tenho como esperar 2 anos... A parte da documentação, acho que muita gente não sabe, 80% do que vale pro hibernate, vale pro nhibernate, e ambos tem uma quantidade razoável de livros e tutoriais.

2013/5/22 Mário Meyrelles <mariome...@gmail.com>

[Henrique Cesar]

Vocês já viram este site de comparação entre os ORM's?

http://ormeter.net/

Os resultados são de 2010, mas mostra o NHibernate bem mal na foto.

Se que de lá pra cá o EF melhorou muito.

Talvez valha a pena baixar os testes e refazê-los com a versão mais recente de ambos.

Abs,

Henrique

[Rodrigo Silva de Andrade]

Se o critério para escolher o ORM para ser usado for performance, você provavelmente nem deveria estar usando um ORM, visto que todos eles são bem rápidos para OLTP. No meu caso, o motivo de escolha entre um ou outro ORM é a liberdade que ele me da para fazer o domínio da forma que eu bem entender. Fora que no caso do NHibernate, existem varias otimizações para que você fazer menos remote calls, coisa que o EF ainda está engatinhando.

2013/5/29 Henrique Cesar <fhen...@gmail.com>

--

[Priscila Mayumi Sato]

[+1] ao Rodrigo.

[Renato Cantarino]

Rodrigo,

e pq eu não posso ter como critério para escolha do ORM a performance?

Att,

Renato Cantarino

[daniel carli]

Porque nada é mais performático que ADO puro, o ganho de performance entre um ORM e outro acaba sendo muito pequeno, e com bom conhecimento no framework utilizado, você compensa esse drawback com cache e coisas do tipo.

Daniel Carli

dcrlz.tumblr.com

[Priscila Mayumi Sato]

[+1] Daniel

atualmente os dois andam pal a pal nesse quesito, então... use outros critérios