2 Pleasant NHibernate Experiences

I've been using NHibernate on a variety of projects over the last year or so, and it never fails to please...

Retrofitting NHibernate
I recently had a project that started out with simple ADO.NET/DataReader/DataSet based data access. After a while, I evolved to using objects for data-structures, and writing simple "loader" classes that took data out of the DB and mapped it into these objects. A few months later it turned out we needed to both read and write these objects to the DB, and at this point I realised my simple hand-rolled data access code had taken me as far as it could. I certainly don't need to re-invent the wheel when it comes to object relational mapping tools.

The interesting thing about this project was that it started out without any need or provision for an O/R mapper: my "data aware" classes didn't even store any DB identity fields because the app never needed them. I was worried that plugging in NHibernate into this existing code base would be tricky - mainly because I hadn't designed the application with that in mind. Fortunately it was remarkably simple - thanks to NHibnerates flexibility.

The grunt of the work was just setting up the mapping files for the several classes that needed reading/writing. Some tweaks to the classes were needed, such as identity fields had to be added. I think the whole process took about a day, and it really was a relatively straight forward experience. It just goes to show you can start simple and then retrofit an O/R mapper if and when you feel any data access pains!

Switching RDBMS from SqlServer to MySql
Roughly 6 months into the project we decided to switch databases from SqlServer to MySql. I'm not knocking SqlServer, it's fantastic, but we basically needed to cut costs, and MySql offered all the features we needed.

When someone comes along and says "can we switch databases", it's can be quite a considerable challenge. However, since we were using NHibernate, all the hard work had been done for us. All I had to do was enter a new connection string and tweak some configuration setttings, and "ping", everything was working against our MySql database. I do recall having to tweak one of the "forumla" fields in the hbm.xml mapping files, but that was it. Unfortunately the app also used some "raw" SQL in places - bypassing NHibnerate, and converting this ADO code + SQL proved to be much more time consuming 8-(

Anyway, there's just a few of my recent but pleasant NHibernate experiences. I'm using version 8.0.4 now, and the dev team are making great progress I think. Good work!

Rails: Frameworks are the way forward!

A few days ago I recieved a chance phone call from a local company in Leeds. They wanted someone to quickly fix some problems in a Rails application whilst thier main developer was on holiday. Have you ever tried to get into someone elses meaty project in just 4 hours!?

This morning I jumped in the car, drove across town to their office, and within 1 hour was in the SCite editor fixing problems so they could get thier demo done. What struck me was just how easy it was to work with a brand-new code base that I've never even seen. It was like being at home inside one of my own projects. Because I know Rails, I instantly knew where to find thing - third party APIs, models, controllers, views, images etc. That's invaluable when it comes to hitting the ground running. The code was very tidy too - clear, concise, well commented which helps alot of course 8-)

I've often been exposed to new code-bases, and half the battle is finding things and getting an understanding of the key abstractions - the framework - that underpins the system. With Rails all this stuff was already known to me - Rails lays out a foundation that you become very familiar with. This meant that finding the appropriate files was a doddle, and I could quickly crack on with tackling the meat of the problems straight away.

I imagine that many frameworks offer such advantages, and it's not just a Rails thing. However, it was a very pleasant surprise to be able to settle in to a code base so easily. In contrast, I've been working on an ASP project for over a year, and even today it's just painful. This particular project is like a "paradigm-soup" where the developer played with scores of ideas in one single project . This isn't a stab at ASP - I've had some great fun with it. Also, I've made that "paradigm-soup" mistake myself (many times). However, I seriously think that it's much harder to screw up when working within the confines of a well thought-out framework. Rails doesn't leave too much room for such amateur blunders!

Anyway, enough Rails evangelism. Rails has tought me an important lesson in the value of frameworks, and I'll certainly be looking to use a framework in all future projects, whether it be based on ASP, .NET or Ruby.