A few months back, I decided it was time to leave stored procedure development behind and focus more on solving true business problems. The first concept I had to get my head around was persistence Ignorance. The idea is simple: I shouldn't have to think about persisting my business objects - something should do this for me and stay out of my way.
Developers tend to view data access strategy as the most religious of topics, and I was no different ... until I realized that my business users couldn't care less about the details of persistence. Beyond reporting, they never once asked me to store something in a database for them. This was an eye opener for me as of recent, because I'm always trying to provide value and true ROI for my customers. Instead of having to write a mess of stored procedures for each project, I can focus on the things my business users care about.
But rather than wait for the usual greenfield application to learn an object relational mapper (ORM), I decided to refactor a previous application to see how flexible something like NHibernate would be.
Why did I pick NHibernate you ask?
- The Summer of NHibernate Screencast Series is excellent
- It's Open Source Software maintained by Ayende Rahien
- More mature than anything Microsoft has to offer
- Testability
- You don't need to inherit from a base class or implement an interface (POCO support)
- LINQ to NHibernate 1.0 was released in July
- The people I most respect are using it
Some of the real fears I had about using LINQ to SQL were related to its inability to provide inheritance for objects represented in different tables. For some odd reason you MUST have everything in 1 table to do inheritance. Also the wording from Microsoft last year about 'support' for LINQ to SQL left me feeling like the ado.net team simply walked away from the technology stack altogether when it was decided that the Entity Framework would be the 'one true way' for data access on the Microsoft platform. And to be clear, LINQ to SQL is not a true ORM.
That brings me to the Entity Framework (EF) ... just the fact that you have to explicitly tell EF that you 'want to lazy load' was enough for me to walk. But the lack of true POCO support here - you must inherit from a base class or implement an interface at the very least - is another big issue for me because I don't like to tip toe around a ton of infastructure just to work with my business objects. In my opinion, a good ORM should stay out of the way so I can do my job. Not to mention the pain that comes along with the drag and drop designer ... need I say more?
I will be starting a series dedicated to NHibernate that will cover some of the pain I felt trying to learn the ORM and back it into a legacy system. A list of the topics are shown below.
- How to get up and running with NHibernate
- How can I model relationships between objects?
- I need to track all changes using some type of audit table - can I do this?
- How can I model inheritance?
- But my application does some valiation, how do I stop NHibernate from persisting these changes?
- What about unit testing? Is it harder or easier with NHibernate?
- What about web services? Can I use something like WCF with NHibernate?
- What about this LINQ to NHibernate thing?
- How to setup NHProf to do some profiling
I learned a ton over the last 6 weeks and hope to share the good/bad/ugly so that others who plan to adopt NHibernate will have a trail to follow.
