C# - Build Your Own ORM - Part 1
ORMs are a touchy subject for many and, unfortunately, one that as developers we eventually have to face. The question usually comes down to whether we should roll our own or use one of the many already available. My choice has always been to build my own, but before I go into the reasons why and how let me list the common reasons cited for not writing your own.
ORMs are often cited to be...
These sound perfectly rational and valid so why haven't I succumbed to the lure of of-the-shelf ORMs? Let's consider the first point, that they are more reliable and efficient. Time and time again I come across issues due to incompatibilities and bugs between third party libraries and frameworks. Usually it'll go something like "ORM A version B is not compatible with database C version D on platform E version F or with another framework/library G version H". To state that ORMs are reliable is to imply that they do not have bugs. They do. And to imply that they are MORE reliable is to imply that your code must be less so. If you are a junior or mid-level developer in a commercial setting then certainly you should not be making the call on whether to introduce an ORM. On the other hand, if you're a team leader or senior developer, surely you're capable of writing reliable, robust, efficient code, and be aware of the additional complexity, maintenance, and uncertainty that comes from making your project reliant on yet another fad-of-the-year library.
Let's look at features. Certainly, many of the larger ORM libraries look great on paper. Tons of features and promises, but like in any sales pitch, it often happens that you will never use or need most of them. No general purpose ORM is ever going to fit your project as snuggly as custom cut code, in much the same way that a tailor made suit is always preferable. So, if you're a great tailor and you need a suit, make it already! Of course, many ORM supporters would cite the various lite libraries available but these are so lite as to make you wonder if you would be better off writing one yourself rather than learning to use someone elses and besides, most management I've come across shy away from having to purchase or use another third party library. Adding an external ORM layer adds extra burden on the skill-set of both existing and future developers. They also make deployment more complicated and add an extra level of uncertainty if the ORM is deprecated or fades into obscurity.
As for saving you time, that would really depend on what you spend your time doing. I would expect any decent developer to already understand the principles of Inheritance, Encapsulation, Abstraction, and Reuse so that they would immediately identify when they are wasting time cutting and pasting code. Save time by reusing your own code rather than someone elses. It's often the case that those trying to "save time" are really just trying to avoid using SQL or other core database technologies such as ODBC, stored procedures, or ADO. This can be the case when their competencies lie elsewhere but there's no denying that to be a good developer you need to know how relational database systems work in the same way that no web developer can ever hope to avoid coding in HTML.
Well that's enough ranting and raving for me. In my next post, let's consider how difficult to build ORMs really are by actually trying to write one.
ORMs are often cited to be...
- Reliable, robust, and efficient as they have been tested over and over.
- Feature rich
- Time saving as they stop you from having to write repetitive code
These sound perfectly rational and valid so why haven't I succumbed to the lure of of-the-shelf ORMs? Let's consider the first point, that they are more reliable and efficient. Time and time again I come across issues due to incompatibilities and bugs between third party libraries and frameworks. Usually it'll go something like "ORM A version B is not compatible with database C version D on platform E version F or with another framework/library G version H". To state that ORMs are reliable is to imply that they do not have bugs. They do. And to imply that they are MORE reliable is to imply that your code must be less so. If you are a junior or mid-level developer in a commercial setting then certainly you should not be making the call on whether to introduce an ORM. On the other hand, if you're a team leader or senior developer, surely you're capable of writing reliable, robust, efficient code, and be aware of the additional complexity, maintenance, and uncertainty that comes from making your project reliant on yet another fad-of-the-year library.
Let's look at features. Certainly, many of the larger ORM libraries look great on paper. Tons of features and promises, but like in any sales pitch, it often happens that you will never use or need most of them. No general purpose ORM is ever going to fit your project as snuggly as custom cut code, in much the same way that a tailor made suit is always preferable. So, if you're a great tailor and you need a suit, make it already! Of course, many ORM supporters would cite the various lite libraries available but these are so lite as to make you wonder if you would be better off writing one yourself rather than learning to use someone elses and besides, most management I've come across shy away from having to purchase or use another third party library. Adding an external ORM layer adds extra burden on the skill-set of both existing and future developers. They also make deployment more complicated and add an extra level of uncertainty if the ORM is deprecated or fades into obscurity.
As for saving you time, that would really depend on what you spend your time doing. I would expect any decent developer to already understand the principles of Inheritance, Encapsulation, Abstraction, and Reuse so that they would immediately identify when they are wasting time cutting and pasting code. Save time by reusing your own code rather than someone elses. It's often the case that those trying to "save time" are really just trying to avoid using SQL or other core database technologies such as ODBC, stored procedures, or ADO. This can be the case when their competencies lie elsewhere but there's no denying that to be a good developer you need to know how relational database systems work in the same way that no web developer can ever hope to avoid coding in HTML.
Well that's enough ranting and raving for me. In my next post, let's consider how difficult to build ORMs really are by actually trying to write one.
