The more I work with NHibernate, the more I question why I wrote so much SQL in the past. It feels… unnecessary. Who said “stupid”? Not me…
Jimmy Nilsson once said, “I just want the database and storage problems to be a consequence of my domain model. I don’t want to think about it.” This aligns with one of the goals of Domain-Driven Design (DDD), and NHibernate is a key tool in achieving this.
I’ve been experimenting with NHibernate recently, and I’m genuinely impressed. While the mapping files can be complex initially and there are many tricks and traps to navigate, NHibernate is truly powerful.
Here are some resources that have been particularly helpful in my journey:
- The NHibernate API Reference
- A great tutorial for getting started
- A series of articles on implementing the Unit of Work pattern with NHibernate: Part 1, Part 2, Part 3
- Advanced mapping scenarios
- Mapping many-to-many entities without requiring a connection entity
Interestingly, we initially attempted to create our own Unit of Work implementation for NHibernate. However, it turns out that NHibernate integrates with the .NET System.TransactionScope. Thanks to Magnus and Calle for pointing that out—my code is now obsolete!
This has been a fantastic learning experience. If you want to see the code, just drop me a line and I’ll send it over in no time.