Learn ORMs

Writing hand crafted SQL is like lighting money on fire, inhaling the smoke and passing out, hitting your head on you computer desk while falling.

Not only are you going to run into stupid typo problems like having the typing the “Products” table as “Product” but your going to waste time working on your own DAL, baking in features like schema to class mapping, lazy loading, caching, and transaction support that have all been written, testing, and battle hardened by hundreds of programmers.

RDBMS persistence is a solved problem at this point and with lots of ORM choices in the market right now, both commercial and open source, its going to be almost impossible not to find one that doesn’t meet your requirements.

The only negative aspect of using ORMs is the learning curve to get up and running with them yet there are more than enough resources around at this point its rare I’m ever stuck with an unsolvable problem. Every ORM I’ve tried ( NHibernate, Subsonic, Linq2Sql ) has had more than enough documentation and newbie tutorials to get started reading and editing database rows within an hour of downloading the assemblies.

When I started out as a developer I wasn’t really aware of ORMs and what they did. At one point I even tried to write my own and was really annoyed when I started using ORMs. All the time spend fighting with SQLCommand wasn’t all that useful once ORMs started appearing in my projects. Writing and debugging SQL is a rare event these days.

The reason I’m writing this post, and that its tone may be passionate, is because I tried responded to a blog post to tell another new developer that he should be using a ORM instead of fiddling with Commands and raw Sql. One of the comments on the post really annoyed me because he blames ORM for problems that would have happened with or without an ORM anyway like tediously complex abstraction layers and being unable to step through a debugger:

I’ve become sceptical of ORMs and abstraction layers. Great in theory but I’ve not yet seen an implementation that doesn’t suck either for maintenance coders or for performance, or both.

I used to be big on following principles when coding. After several years of contracting, working on existing code bases, I’m now in favour of practicality. I rate everything now based on the two criteria I mentioned above:

1) Is it easy to maintain?
2) Is the performance adequate?

Almost all the code I’ve come across fails one or both of these two criteria.

The code-base I’m working on at the moment is a case in point. I need to change the way the data is stored in the database. First step, reverse engineering the existing code to find out how it saves the data. 10 – 12 nested methods between clicking a button on the UI and something happening in the database (not to mention side calls to read properties or get specific data). And slow as a dog. All the business logic in the middleware layer. Great idea but it involves 3 database writes and 4 reads to add an item to an order. Maximum of 99 items can be added at a time. I make that up to 693 database accesses to perform a single operation (adding a bunch of items to an order). It took two days to rewrite the code to perform a single database update for all items. Still using a data access layer but moving the business logic to a stored procedure in the database. No good from a purist’s point of view but all the business logic is in one place (the stored proc) and we got a several hundred-fold improvement in performance, on average.

My .Net learning experience was full of reading comments like that when deciding how to handle rdbms persistence. Being unable to separate what was just bad programming and an actual issue with a piece of technology I decided that ORMs weren’t worth it and fought with raw sql strings for months.

ORMs are a big part of the future of programming. All major Django, Php, and Ruby frameworks are based off an internal ORM and Microsoft is shipping two at the moment which don’t seem half bad. Chances are your going to encounter a lot of ORMs in your professional career and learning them will be a definite benefit to your overall productivity and job opportunities. I probably lost a job last month because I didn’t have any NHibernate experience at the time. I just wish somebody told me earlier, like I am now, so I wouldn’t have wasted time trying solve a solved problem.

This entry was posted on Tuesday, June 09th, 2009 and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or Trackback from your own site.