// On Rolling Your Own ORM

My last post was scratching a personal itch. I've been plenty guilty in the past of needlessly reinventing the wheel. Sometimes due to honest ignorance of an existing solution. Other times it was a more willful ignorance because I didn't want to do the research or "didn't have the time." That's a terrible excuse, by the way. Still other times in my hubris I thought I could do it better without ever really trying an existing solution. I'd like to think these mistakes are forever behind me and that I've learned to do better. In truth, I'm still growing and learning as a developer and I suspect that process will never end. Still, anyone who learns to recognize a problem of any kind will itch when they see it and I've been itching. A lot. I've come to welcome the itch, though, because despite it's downsides it drives me to learn and grow, even when the itch isn't self-inflicted.

In this case, the problem at hand is how to handle database access and choosing an existing ORM vs rolling your own. This is a very common theme in c#, it would seem, and there are many existing ORMs available. When you buy into the idea that code is a liability and making use of an existing solution is usually the best option, the option of building your own ORM becomes very unpalatable. I could go on, but LosTechies summed it up nicely in their post titled "Don't write your own ORM."