I haven’t been around every block, but I have seen many ways people have cooked up mappings between a persistent layer, typically a database, and some sort of object model, whether a business oriented domain or just a bunch of objects. Probably the worst I’ve seen has been data classes with methods like Select(), From(), Where(), Group() and bits and pieces of dynamic sql spilled all over. It was impossible to follow or comprehend. I’ve seen other approaches, including myself, that is ordered, neat, and works well, but isn’t something I’d call great. The concept of object to relation database mapping isn’t new, so when I started looking at some of the frameworks out there, I said to myself “why haven’t I been using this sooner?” One ORM in particular that caught my eye was NHibernate, which is a port from a ORM in java called Hibernate. It’s got a bit of a steep initial learning curve but once you got this engine firing on all cylinders, damn this stuff is cool. One of the core concepts that really caught my attention was that fact that NHibernate stresses domain driven design. In a nut shell, forget about the storage of your data objects and focus on what you business model is and how it works; deal with the persistence later because that’s what the “mapping” part is all about. Of course there is a bit of give and take because you might be trying to use this ORM with a legacy database system that doesn’t easily fit into a nice domain model. Also, NHibernate doesn’t solve all the database mapping scenarios, although I would say it could follow the 80/20 rule: it will solve 80% of the most common scenarios, leaving only 20% to some other type of technological solution.
Anyway, I’m not going to give a full demo of how it works, there will be links at the end of the post that can get you started. The following 4 items are all that is needed to get up a running:
- Some domain model with a mapping to a persistent layer (i.e. a database). The mapping can be done a few different ways, but the concept is that you indicate how your objects will map to given database tables/columns.
- Enter the correct app.config settings. The configuration settings tell NHibernate information like what type of database it’s talking to and how (i.e. SQL2005, MySql, Oracle, etc).
- Generate the session factory in you app, preferably only once such as a singleton. The SessionFactory is in charge of generating proxy classes for you mappings. If you get stuck by why properties have to be virtual on some of your mapped classes read this.
- Use the session object to interact with the persistence layer. The Session is the item used the most, it’s kind of like a database connection/command in that you have to open it and commit stuff and close it when your done, but that’s as far that analogy goes.
It’s amazing how much time one can save on the mundane tasks of persisting your hard work you put into your domain model. This is the biggest selling point for me, as importance of your enterprise application isn’t general how you going to save data object but how do these data objects relate to each other.
Good book: NHibernate in Action