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...
share|improve this question
1  
You can find some of the common mistakes here: NHProf Alerts –  VahidN Aug 11 '11 at 7:42
1  
Also there are some valuable posts here about NHibernate Pitfalls –  VahidN Aug 11 '11 at 7:45
add comment

migrated from stackoverflow.com Aug 12 '11 at 6:53

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 25 down vote accepted

My personal "frequently explained" issues:

Anti-Patterns

Messing around with detached objects (SaveOrUpdate or Merge plus some messy code) instead of using DTO's. The more complex the entities are, the messier the code is. (It also means that it works quite well with trivial entities.) Ayende also calls it the Stripper Pattern and explains the encapsulation issue.

Not understanding persistence ignorance and writing NH applications as when using explicit SQL. Symptom of that: calling Update after changing an object, wondering why changes are persisted even if Update had not been called, wondering how to avoid changes to be persisted.

Not understanding transactions and the unit of work pattern. Frequent anti-patterns: implicit transactions, session-per-operation and session-per-application. Some more reading:

Using NH events to put application logic in (eg. change tracking in insert and update triggers)

Create one class per table. Some people don't understand OOD, others don't understand relational design.

Mistakes

use of one-to-one instead of many-to-one. I tried it to explain in this answer.

Using join fetch in combination with SetMaxResult. My latest answers related to that topic:

Writing self changing entities. When an entity doesn't exactly return the value that had been set by NH, it is considered dirty and gets updated in every session. For instance: replacing the NH persistent collection in a property setter.

  IList<Address> Addresses
  {
    get { return addresses; }
    // will cause the addresses collection to be built up from scratch
    // in the database in every session, even when just reading the entity.
    set { addresses = new List<Address>(value); }
  }

  int Whatever
  {
    // will make the entity dirty after reading negative values from the db.
    // this causes unexpected updates after just reading the entity.
    get { if (whatever < 0) return 0; }
    set { whatever = value; }
  }

May be more is following.

share|improve this answer
1  
+1: You should add "Not using Unit of Work pattern" and "One session per application" to your list imho. –  Falcon Aug 12 '11 at 7:41
    
@Falcon: yeah probably. It's a general "not understanding transactions" problem. The unit of work is a bit covered by persistence ignorance. Although they are completely different concepts, they result in the same patterns. –  Stefan Steinegger Aug 16 '11 at 10:33
add comment

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.

share|improve this answer
add comment
  • Too many abstractions
  • Not using Automappings with FluentNHibernate
share|improve this answer
    
The first point is a little vague, but in case you are referring to silly notions such hiding ISession behind a "Repository" or "DAO", I agree. –  chris Jan 7 at 14:54
    
The second point however is nonsense. There are good reasons why we often want to have fine grained control over the physical data model and be able to decouple that from the domain model. After all, that's the point of the "M" in "ORM". Using automappings (while useful in simple scenarios) defeats that. Besides, there is also the issue of integration legacy database schemas, for which automapping is useless. –  chris Jan 7 at 15:00
    
I use the inbuilt by code convention based mapping. It handles a great swath of crap I would otherwise have to repeat. However it still provides the freedom to but entity specific customisation that are layered over the mapping generated by convention. Its super helpful. –  Sam Feb 3 at 3:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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