Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What are the most common mistakes and anti-patterns NHibernate user programmers make? Please explain why those are bad practices or give link to resource for further reading.

For example:

  • One anti-pattern common for new NHibernate programmers is to use identity/native POID's instead of ORM style onces. Read more here...

migration rejected from stackoverflow.com yesterday

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

put on hold as too broad by BЈовић, Bart van Ingen Schenau, Kilian Foth, MichaelT, Doval yesterday

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

You can find some of the common mistakes here: NHProf Alerts –  VahidN Aug 11 '11 at 7:42
Also there are some valuable posts here about NHibernate Pitfalls –  VahidN Aug 11 '11 at 7:45

2 Answers 2

The "Select N+1 Problem".

This is where you end up executing A select for each entity you want to manipulate (N), and a select to get the list of entities (+1), instead of a single select of all entities and their attributes.


Trying to abstract it out so that you can switch to Entity Framework (or something else) at a later date.

This is much, much harder than most people who attempt it realise. There are numerous differences between the two that can trip you up in ways that can be quite subtle at times. It's also very uncommon for it to actually be needed in the end -- so much so that you can be meticulously trying to implement it for years before discovering that your approach is all wrong.

Also, it restricts you from using a whole lot of NHibernate's useful and important features such as second-level caching, interception, concurrency management, change tracking, prefetch queries and so on.

If there really were a valid need to switch between NHibernate and Entity Framework, there would be an actively developed project to support this on GitHub (perhaps something in a similar vein to CommonServiceLocator) with numerous contributors and pull requests.


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