At the beginning of the year, I described the horrible experience I had while removing *TWO* columns from the database of a legacy system here at the day job.  For those too lazy to go back and read, I basically spent nearly an entire day working on this “trivial” task and ended up with a 15,563 line SVN diff spread across 40 files.

Yesterday I was tasked with making major changes to the object model we’re persisting.  The change consisted of *nine* new entities and one modified entity.  Compare this to the simple deletion of two columns/properties, and you might think that this single task would take me the rest of the year.  And you would probably be right, except something is different this time.  This time, I’m working on a project that uses Castle ActiveRecord for its data access.

Again, for those who are too lazy to read, what does that really mean compared to the hand-rolled DAL I described 6 months ago?  The hand-rolled DAL consisted of several layers: a generic (massive) interface, two huge, concrete implementations of that interface (one for unit testing and one that actually talked to SQL Server), stored procedures, and the actual tables.  Oh, and a web service layer on top, just for good measure.

On the ActiveRecord (AR) side, I have my AR objects, which inherit from generic AR base classes, and the database… and that’s it.  All CRUD and querying capabilities are inherited from the generic base classes.  LINQ is supported through the generic base classes.  Unit tests are seamlessly handled by AR via SQLite. I have a simple ad-hoc method that I can run with TestDriven.NET that generates the database schema from my object definitions, and the application itself currently has the capability to upgrade its own schema as the objects change (such functionality is dangerous, but this app is still in the rapid prototype/evaluation stages). 

Clearly, the AR approach sounds a lot simpler with no stored procedures, no massive DAL objects, and automatic schema maintenance, but how much time did it *really* save?

I did the math.  I added things up, and there were over 50 database additions as part of this update.  Looking at my old timesheets, it took me 8 hours to complete the removal of *two* columns.  So, it should have taken me about 200 hours to implement these changes. :D  How long did it really take? 

Less than a day.  That includes time spent designing the new objects on paper, creating the classes, and figuring out how to handle one tricky mapping that involved an interface and a one-to-one relationship (which cost me about 2 hours).  I don’t even want to think about how long this would have taken if I’d done it by hand.

I think ORMs have advanced from “cool tool” to “required knowledge” for software developers.  If you consider yourself a developer but don’t know how to use at least one ORM, now would be a great time to acquaint yourself with one. My (biased) opinion is that Castle ActiveRecord is a great place to start. There are also others checking out, such as NHibernate (which ActiveRecord is built on) and Nvigorate.  At this point, I can’t imagine I will ever build another data-driven application that doesn’t use an ORM.  The alternative is just too painful.