Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the past 2 years since I started writing business applications (before I did either high level front end or very low level systems programming), learned datasets, linq to sql, and now entity framework. The logical thing to look at next seems to be NHibernate.

Reasons I eventually ended up at EF are: (1) it has the best designer support and (2) it is the most supported by Microsoft.

Reasons (these have elements of assumption) I am interested in NHibernate are: (1) it might not get superceded by a totally different thing as quickly as MS churns data access technologies (2) It seems like its either the front running or second to front running tool for what it does and (3) It appears to be stable and tracable back through time quite a bit.

Has anyone published a comparioson of the two? Is one better than the other for certain types of architectures? Or is it just a matter of style and preference?

share|improve this question

closed as not constructive by Yannis Feb 28 '12 at 18:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 6 down vote accepted

At this point I think the main (only?) advantages NH has over EF are some very fine-grained fetching strategies. Instead of lazy-loading OR eager-loading everything, NH gives you some very nice intermediate options.

Having said that, I've never needed that level of control over my data access, and so the simplicity of EF has made the choice an easy one.

Just be aware that the EF designer file that's otherwise so nice to work with can become a nightmare in source control; it doesn't merge well, or at all. Make sure you check it out with an explicit lock anytime you need to change stuff.

share|improve this answer
+1 for the designer thing. I had no good experience with anything related to a designer. – Codism Aug 19 '11 at 21:59
don't forget the ability to always work with a DB other than SQLServer. EF generates non-standard sql in some cases. – gbjbaanb Aug 19 '11 at 22:15
could you get around the merge problem by putting the designer file into your ignore list and re-generating, because the changes are reflected in the edmx file? – Aaron Anodide Aug 19 '11 at 23:36
@Gabriel, I think the edmx file is what causes the problems. People update the designer, which changes the edmx, then check-in, and if others have done the same, all hell breaks loose. – Adam Rackis Aug 20 '11 at 2:07
If you download the download the (official, Microsoft supported, but not included in .NET 4.0) EF 4.1, you can use Code First and put together your mappings very similarly to FluentNHibernate. Works very well with source control. – Aaronaught Aug 20 '11 at 3:37

We're doing a project where the architect chose NHibernate over EF. I wish the choice had gone the other way as a publisher-subscriber requirement was present from the beginning.

If you plan on using sync framework, go with EF, as NHibernate can't cope with the updates (to the columns that specify where the data came from, who changed it and is my copy the latest) that go on behind the scenes.

If you need to replicate data from one database to another (and keep primary keys the same), the session.Replicate function is poorly documented and seems to take longer than a straight copy.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.