views:

1885

answers:

3

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 http://stackoverflow.com/questions/658824 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.

+4  A: 

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.

NoCarrier
PErsistence ignorance seems to be planned for EF v2.0 which should ship with .NET 4.0 / VS 2010, sometime early in 2010
marc_s
Thanks for the info. Good to hear persistence ignorance is coming in v2. Will have a look at the adapter, hadn't seen that before. But in the next 18 months I think I'll be sticking mostly with NH. I already learned how to write those darn config files ;)
tyndall
... and now you'll have to unlearn mapping again, as everyone who's "cool" now does it fluently :) http://fluentnhibernate.org/
HenningK
+2  A: 

I would probably be avoiding the entity framework altogether for now. There's the vote of no confidence that the famework was given, not to mention it's not as mature as NHibernate.

Having said that, I would continue to evaluate the entity framework as I'm sure it will be improved over time.

lomaxx
+1 had seen the "vote of no conf", and the blog posts about the missing or lacking functionality. But your right about it improving. Microsoft usually gets stuff right by the third try.
tyndall
+4  A: 

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.

HenningK
+1 good thoughts. You don't have to sell me on NHibernate. I have been digging into it for about 3 months now. I find it much more customizable and modular than EF. The NH way of doing it speaks to me. LINQ with EF still feels a little foreign.
tyndall
Will read up on the RIA Services.
tyndall