Solving The Wrong Problems

Is there any justification in this day and age for hand rolling your own data access layer?
Simply put, no. So don’t.

Same goes for messaging. Why build your own framework on top of WCF and be responsible for forever having to bend it to meet the latest requirements?

Today there are countless ways to get data into and out of an application, all of them encapsulating the tedium, pain, and experience of those who’ve gone before so that you don’t have to. For data access there’s LinqToSql, Entity Framework, NHibernate, Castle ActiveRecord, Subsonic, and many others. For messaging there’s NServiceBus, Mass Transit, and Rhino Bus. Yes, they all have a learning curve but learning is what this game is about. They all have their own pros and cons but if you never try them you’ll never know when (or not) to use them. And despite the effort required to learn one or more of these frameworks, you can guarantee that the effort is less than say, writing repetitive Insert, Update and Delete methods and the many stored procedures that usually follow close behind. And let’s not even mention the maintenance cost of all that hand-written code over the lifetime of the application.

I agree that for CRUD applications, NHibernate is probably over the top and ill suited. On the other hand Castle ActiveRecord  (which is built on top of NHibernate) will more than likely be a very good fit and will eliminate a massive amount of code and code that you don’t have to write is code that you don’t have to fix. Having said that, writing data access code is such a well understood “problem” that I can sort of understand why it’s done but writing your own messaging system is another thing altogether and it’s something I’m faced with having to extend at the moment. How anybody can think they understand the implications of durable, transactional messaging well enough to build their own framework for enterprise use is beyond me (unless they’re Udi Dahan, or Dru Sellers and I’m pretty sure they’ve never worked for my current employer). Why would you do this when you could use NServiceBus for example? There are ready-made off the shelf solutions to these problems so why not use them?

This argument isn’t even new. Jeremy Miller (amongst many others) posted about it three years ago, and I totally agree with his conclusion.  All the arguments about not liking the SQL generated by an ORM just don’t wash. The chances are you just don’t know the ORM well enough to be able to tweak it (and if you do then you already also know that where there really is a problem, you can replace that bit with your own SQL if you need to). Most ORMs have had thousands of hours poured into them. They work, we just need to learn how to use them.

In the end the responsibility lies with us as developers to know and understand our options and that means taking the time to study new things so we can make an informed decision. Then we’ll make the right choice, not just for us but for the developers who come after us and are tasked with maintaining or extending our application. If we use established and proven readily available solutions then we can get on and solve the problems that really matter to the business. That’s what they want and that’s how it should be.

Solving The Wrong Problems