ADO.NET Entity Framework and NHibernate - when to use one over the other

Question

I am working in a Microsoft .NET shop where it is okay to use NHibernate or ADO.NET EF. What guidance should we be using about when you should choose one over the other?

For example, it seems like when writing a Silverlight app the EF -to-> ADO.NET Data Services -to-> Silverlight would offer a productivity boost, and provide you with a REST service API for no extra effort.

What other things should help guide you on an app by app basis?

UPDATE (based on comment): This one is slightly useful What differentiates Nhibernate from other ORM’s? the others go off into weird tangents (like SubSonic) and don't directly compare the two. I guess I'm specifically looking for people who use both, and decide on a project by project which one they will use.

Answer 1

In a nutshell, EF has no Persistence Ignorance support out of the box. When i first tried building a solution with EF last year, i was a bit annoyed that you can't have POCOs in your application. I wanted a higher degree of decoupling with my model so i ended up switching to NHibernate. Since then, someone's written an EF POCO adapter. http://code.msdn.microsoft.com/EFPocoAdapter - however its really just a codegenerator that generates an adapter layer to map your objects.

For some reason, my app ran a bit faster under NHibernate as well. Take that with a grain of salt because i was new to configuring either solution.

Answer 2

Microsoft has recently begun developing a new solution, called .NET Ria Services (for now), that will be "ORM independent" for getting data into and out of Silverlight from a business logic layer living on the server.

They've publicly mentioned (on slides at MIX, even) that NH WILL be supported here.

If you're looking for a solution that has the most community support, NHibernate is definitely the answer. I'll concede that it has a steep learning curve, but in my experience it is most certainly worth it. Just do a comparative search for "entity framework" and "nhibernate", and you'll see what I mean. Most of the EF stuff will be "press", while the NHibernate stuff will actually be down-to-the-guts technical, gory details. And questions. Being answered.

But as other posters have mentioned - I'm sure the Entity Framework will improve over time. For now though, I believe they're trying to solve too many problems with one toolset. NHibernate does just one thing, but does it exceptionally well.

There's also the issue of application design here. EF seems to be (in its current incarnation) built to deliver a database to a C# application. NHibernate goes the other way, and makes it easier to get an object model persisted.