ADO.NET Entity Framework vs NHibernate

Question

So the ADO.NET Entity Framework has gotten a little bit of bad press (in the form of blog entries and a petition) but I don\'t want to rush to judgement. I\'m limited in tim

Answer 1

Microsoft have all but admitted that the ADO.Net Entity Framework isn't an ORM (I can't find a reference currently). So if you think of the Entity Framework as a query engine then apparently it is really good at what it does. For a complete ORM solution you might want to look elsewhere however.

The following blog post seems to bear out this difference:

http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx

Answer 2

I've used SubSonic, LinqToSql, LinqToEntities. Now i'm trying NHibernate. For now - i like NHibernate (probably cause i haven`t met problems enough). Worst of them all - LinqToEntities (that's only my opinion, of course).

Answer 3

If zero configuration is main advantage of SubSonic you can look at Fluent nHibernate or Entity Framework Code-First

UPDATE from Răzvan Panda: Fluent NHibernate has been mostly made obsolete by inclusion in NHibernate itself of mapping by code, see: notherdev.blogspot.ie/2012/02/

Answer 4

It has been 2 years since the original post. From what I understand ADO.NET Entity Framework has matured in with .net 4. Does anyone have any new feedback on this topic?

Here's a link to the improvements added to EF since first release in 2008 http://blogs.msdn.com/b/adonet/archive/2009/05/11/update-on-the-entity-framework-in-net-4-and-visual-studio-2010.aspx

Update: I found this thread on stack overflow that does a nice job of discussing the updated EF:

Entity Framework 4 vs NHibernate

Answer 5

I am coming around to liking Entity. It takes a while to figure out what all of its error messages mean but once you get used to it it really does a great job. The biggest drawback it has right now is no real support for going disconnected.

Answer 6

NHibernate may be more mature. That does not necessarily mean it is a "better" solution. Having used it at my job for some time, I would personally prefer to use almost anything than NHibernate (even straight SQL, if migration were remotely feasible). The number of error messages thrown by NHibernate that don't mean anything (or that do mean something but should never occur) is absolutely staggering, as are some of its default behaviours (such as flushing the session once for each object returned in a Find).

Personally, when I have a choice, I use LINQ to SQL for all database work.