I'm wondering how others layer their apps with NHibernate. After looking at all the sample apps I could find, I concluded that something similar to Ben Day's bug tracker was the way to go: http://blog.benday.com/archive/2005/03/16/198.aspx.

So my layers looked like:

UI Layer
Service Layer - For handling use cases and transactions
Domain Layer - Entities and their business logic
Data Access Layer - wrapps NHibernate and has a DAO for each entity in the

So, for example in a code behind if I want to get a User object I call

new UserService().GetUser(int ID)
which in turn calls
new UserDao().GetUser(int ID)
which in turn calls NHib to get the User

However, in thinking about it seperate DAOs seem to be overkill. I think its better to call a generic DAO which wraps NHibernate in my service layer

so the old UserService.GetUser was:

return new UserDao().getUser(ID)

the new one would be

return new GenericDao(typeof(User), ID)

In this way I don't have to bother with seperate DAO's.

Does anyone have any comments on this? How do you architect your apps?

It is important to have different DAOs (or Repositories), one for each persistent entity for which you need to execute explicit queries against the database to retrieve. Entities that can be reached by association (like order items from an Order) do not need their own DAO.

Custom query logic, appropriate for a given persistent entity is then accessed via methods on the corresponding DAO. If you have a single generic DAO, then all queries for all persistent entities will appear on the same class which is badly organised.

You should create a generic base class from which your specific DAOs derive (see http://www.hibernate.org/328.html).

It is also best practice to implement your DAOs against interfaces so that the DAO implementation can be replaced with mocks/stubs during unit tests.