C# – Why is the Repository pattern needed in NHibernate

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.

• I tried to explain it in this SO answer
• Read how flushing works in the reference documentation.
• A blog post by kurtharriger who is criticizing exactly what is actually one of the main features (as a prove that it is a common misconception about NH)

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

• Fabio Maulo: Conversation-per-Business-Transaction
• On nhforge.org: Effective NHibernate Session management for web apps

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:

• Why doesnt NHibernate eager fetch my data (with some more notes about side effects in the comments)
• Hibernate - How to make associations eager
• NHIbernate 1.2 And Lazy Loading
• Pagination with Hibernate criteria and FetchMode.JOIN

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.

Generic repository is even useless (and IMHO also bad) for Entity Framework. It doesn't bring any additional value to what is already provided by IDbSet<T> (which is btw. generic repository).

As you have already found the argument that generic repository can be replaced by implementation for other data access technology is pretty weak because it can demand writing your own Linq provider.

The second common argument about simplified unit testing is also wrong because mocking repository / set with in-memory data storage replaces Linq provider with another one which has different capabilities. Linq-to-entities provider supports only subset of Linq features - it even doesn't support all methods available on IQueryable<T> interface. Sharing expression trees between data access layer and business logic layers prevents any faking of data access layer - query logic must be separated.

If you want to have strong "generic" abstraction you must involve other patterns as well. In this case you need to use abstract query language which can be translated by repository to specific query language supported by used data access layer. This is handled by Specification pattern. Linq on IQueryable is specification (but the translation requires provider - or some custom visitor translating expression tree into query) but you can define your own simplified version and use it. For example NHibernate uses Criteria API. Still the simplest way is using specific repository with specific methods. This way is the simplest to implement, simplest to test and simplest to fake in unit tests because the query logic is completely hidden and separated behind the abstraction.