Please, Just Remember One Thing
Just for a few seconds forget everything you know about NHibernate.
Now, before I snap my fingers and everything comes flooding back, the only thing you need to know about NHibernate is that whenever you need to, you can easily circumvent it and do whatever is needed to get the job done (like use an IDbConnection and IDbCommand to execute a stored procedure).
I often hear people saying it, and often say it myself, but people just don’t seem to get it. You use NHibernate to save yourself from having to write a ton of code for 95% of your data access, and then, after profiling, optimize the critical 5% with whatever other approach you prefer. Its stupidly easy. You can access an IDbConnection directly from an NHibernate’s ISession, or subclass your NHibernateDataAccess class with an SqlServerDataAccess class and override those critical sections.
Instead of taking the above sane approach, I see people laboring through huge amounts of mundane code in order to keep control over that unique 5% (maybe a special report, or performance sensitive path). I see people concerned about performance, without understanding that for most of what an application does, the performance difference between method A, B and C are indistinguishable, whereas the maintenance and developer costs vary hugely.
Essentially I see people who are worried about not being able to tweak when necessary and people who simply don’t want to change.
To the first group I say that your fears are understood, but not to worry. You can always drop down to the assembly of data access (SQL, Sprocs, …).
Four Areas of Improvement
NHibernate makes my life easier and my code better, but it isn’t without problems. A lot of these have to do with the fact that it’s trying to solve a complex problem, of which numerous variations exist. As such, NHibernate’s biggest problem is that it’s hard to learn and harder still to master. There are some specific pain points I’d like to see addressed.
First, mapping needs to be simplified. It’s extremely intimidating to a newcomer and requires that you understand most of the fundamentals. This is already being addressed with FluentNhibernate and hopefully the project will continue to mature.
Secondly, collections and references can be particularly puzzling. From the names used (bags, maps and sets are all foreign to most .NET developers), to advanced features like caching, lazy loading and cascading. I’m not sure if this is something that can actually be improved, or if this battle needs to be fought via documentation.
Thirdly, neither HQL nor Criterias feel like the most natural querying languages. Hopefully development on Linq to NHibernate will continue to be a priority.
Finally, NHibernate is an abstraction that will leak. This shouldn’t be unexpected, but it would be nice to try and address some of the worst offenders. The leaks that continuously trip me up are related to management of ISessions. Lazy loading and session management is a black art – doubtlessly easy for masters, and frustrating for everyone else.
NHibernate and Microsoft
Microsoft has long been criticized for its attitude towards open source frameworks. The common approach appears to be to compete with established open source frameworks using inferior solutions. MSTest, MSBuild, Sandcastle, ASP.NET Ajax, ASP.NET MVC, Entity Framework, Unity, Logging Application Block, Velocity, Team Foundation SSC are all examples that come to mind.
It’d be nice if Microsoft took a different approach with NHibernate, by not only acknowledging its presence and using it in samples and demos, but also actively contributing to it. Remember, during NHibernate’s lifetime, Microsoft has invented three distinct data access strategies (DataSets, Linq to SQL and the Entity Framework). So much effort, so much relearning by developers, to end up with a poor replica of NHibernate years later.
A couple years ago, Google contributed Hibernate Shards to the Hibernate project (and I’d bet that they’ve been involved in Hibernate in other ways since then). Surely Microsoft can help fund the project in a manner that works with the NHibernate team (money or resources).
NHibernate and You
I do think it’s important for any developer to learn new things. Equally important is to learn them from different people. Its important that you learn Ruby or Python, not because you should use them, but because seeing MVC over ActiveRecord completely changes your perspective on how applications can be built. The more approaches that you know, the more likely you are to pick the right one for the job. If you only know one approach then you’ll always use that one – and you better hope like hell that the person selling you that approach knows what he or she is talking about.
As for NHibernate specifically, most developers should learn about O/R mappers. You should know the advantages and disadvantages and therefore know when a situations calls for it or not.