I have written an article on codeproject.com concerning NHibernate with ASP.NET, Generics and unit tests. The demo code leverages an abstract DAO factory and includes code for unit testing NHibernate along with unit testing mock-NHibernate-DAOs to make it easy to test business logic without invoking a live databse. So far the article is getting good reviews, but, at the risk of drawing more critical reviewers, I'd like to elicit feedback from the NHibernate dev team and other NHibernate users.

The article can be found at: http://www.codeproject.com/useritems/NHibernateBestPractices.asp.

As a follow-up, I'm planning an article on using NHibernate in an agile project life-cycle. A discussion thread has begun at the bottom of the article concerning this...any suggestions/requests on this would also be appreciated.

Thank you!
Billy

Great article!

Good article,

However I gonna go ahead and suggest that DAO + Entity approach to persistence is not the only one and definitely can not be called the "best" as the article suggests.

Some (google Eric Evans) people think that it's more important to capture the domain model than build a framework. I would also question the "universal" aspect of business layer being not aware of the semantics of persistence. If the argument is testability of the business layer - you can mock ISession, can't you? If it's implementation details - you are not suggesting that I can switch my business layer to use webservices implementation and not notice it? In fact how much (reallistically) of my business layer can be written w/o certain assumptions about the overall architecture?
Example - I've got a customer with a collection of orders, nicely mapped to my tables courtesy of nhibernate (Y), i need to answer a business question - count of certain orders. As far as my business layer is concerned, i've got the data - it's in the collection! But evaluating the Orders collection could be ridiculously expensive (in real life), I know I need a query - so much for transparent data access. If the answer to simple question like that has to be in my DAO, how much of a business layer have i got?

Respectfully stand to be corrected... :)

Cheers,
E.

Great arguments! I'll attempt a convincing reply. You're right, one size does NOT fit all - using "best practices" may have been a bit presumptuous. As Eric Evans reiterated time and time again in Domain Driven Design, it's important to allow the domain model, not how the data is stored, to lead development efforts. So in essence, there's no such thing as true "best practices" - the best practices are to be redefined with each and every project according to the requirements of the domain being modeled.

What I attempted to do in writing the "best practices" article was put forth a stong starting point for creating enterprise level web applications that still allow for domain driven development. To support this, the sample framework provides examples of mocking database access so that database details can truly become an implementation detail - an afterthought to the domain. But you are also right in saying that, in practical terms, the business logic layer must have some knowledge of the data access layer to avoid ridiculous scenarios of loading a million records from a database to match just six of them. The important point to emphasize is that the business logic layer should only work with the data access layer via abstractions. (See Robert Martin's Agile Software Development for many discussions concerning this.) Another important point is that the business logic layer should not, arguably, create its dependencies to the data access layer directly - its dependencies should be injected to keep coupling loose. Not only does loose coupling allow for more flexible unit testing, it is also a strong tenant of objective OOP best practices.

IMO, the framework I've put together is minimally intrusive while allowing great flexibility in providing data access. In the sample application, data communications are always through abstractions yet still allow for more fine grained control to optimize data access capabilities. As you pointed out, fine grained control is needed at times when a generic DAO doesn't fit the bill. To facilitate a lower level of control, the interfaces for each DAO may be extended to provide methods such as GetSalesOrderByDateRange(). (See the second code block example at http://www.hibernate.org/328.html for more on this.)

But again, as you've mentioned, it's inappropriate to imply that one solution is the "best" solution in every situation. But I expect the sample foundation I've put together should at least qualify for the 80/20 rule while still supporting a domain-driven approach to development. And if a project falls into the "20" category, then the suggestions I've put forth should be quickly dismissed...and I'd be the first to throw them out the window! ;)

Billy