TL;DR: ORMs, like everything in this world, have a time and a place.  Figure out where it makes sense to use them and use something else when ORMs don’t make sense.

ORMs are a hotly debated topic in the world of programming.  There are countless impassioned blog posts from programmers discussing how ORMs either killed their pets or cured their aunt’s cancer.  Why, oh, why is this talked about so much?  Aren’t there more important topics at hand, or are our lives so void of conflict that we have to sit and argue about this till we’re blue in the face?  Can’t we just move on and accept that ORMs are a part of our lives, and that, in some cases, they can even be good?

(Yes, I get the fact that by joining in on the conversation, I am being a hypocrite.  I promise to keep it short.)

I read a post recently that got some attention on Reddit’s r/programming.  The gist of it was, if you’re going to use an ORM, you might as well just learn and write SQL.  But this post (and all posts on ORMs, including my own) should be taken with a grain of salt – the author says it all at the end of his post:

“It should be made clear that I am not claiming this is how all applications should deal with a database.  All I am saying is that this fits my use case based on the data I am working with.”

So… all that impassioned discussion, for what?  To come to this startling conclusion?

“I use SQL because ORMs don’t fit my particular application.”

I gotta tell you, that right there is riveting. (I understand I’m oversimplifying.  Don’t take my sarcastic jives too seriously.)

Not to say that the author’s article had no value – it makes some good points about the weaknesses of ORMs.  And let me be clear: learning an ORM is not a substitute for knowing and understanding SQL.  My experience with both hand-coded ADO.NET (.NET’s most simple database access library) and Entity Framework (a Microsoft-supported ORM for .NET) has taught me to know when you use one and ignore the other.  But for most new projects, the first thing I do is model my database in Entity Framework (either Code First or Database First, depending on the scenario.)  Which leads me to answer this one, simple question.

Q: Spencer, why do you use ORMs?

A: Because they deliver business value by allowing me to get things done quicker. Do I want to spend my time writing and debugging typo-prone, hand-coded SQL queries or making THINGS that do STUFF that businesses want?

Donald Knuth’s nugget of wisdom, “premature optimization is the root of all evil,” is so very true.  Oftentimes, ORMs are ignored because they are “leaky abstractions” and “too slow.”  Yes, they’re slower than hand-coded ADO.NET.  But guess what else is slower as a result?  *Me.  *How can I maximize my productivity when I’m sitting there writing things like this:

When I could be writing things like this:

Or this (for primary key lookups):

Or this, if you prefer query syntax (in this case, I don’t):

Bottom line: ORMs help me deliver more value to the company I work for.  If I work faster, they get more productivity out of me.  Not to mention that it gets me to the fun stuff faster.  That’s about all I feel I need to say.  But I’ll say a little more and talk about one company’s experience with ORMs.

StackOverflow needs little introduction – it’s one of the biggest websites on the Internet.  It’s built on ASP.NET with a SQL Server backend.  Most if not all queries ran through LINQ to SQL, an ORM similar to Entity Framework.

LINQ to SQL is far slower than hand-coded ADO.NET, but did that matter?  In fact, it did, but only when LINQ to SQL wasn’t fast enough.

Sam Saffron, co-founder of StackOverflow, determined that LINQ to SQL was too slow in certain parts of StackOverflow, and wrote his own ORM, Dapper, to handle the queries that were computationally expensive to run on his application layer.  The result for them was faster load times for some of their webpages.

Dapper is nearly as fast as hand-coded ADO.NET and is of course much faster than LINQ to SQL, but Sam didn’t ditch L2S right away either and tells you not to do the same.  In his words (emphasis my own):

I would not recommend people go crazy and dump LINQ-2-SQL just because of this. My recommendation would be: measure, find bottlenecks and fix the ones that matter.

So, there you have it.  Agree?  Disagree?  Sound off on twitter (@schneidenbach) or the comments below!

EDIT: Changed “error-prone” to “typo-prone” in my little Q-A.  People seemed to think I meant SQL was error-prone, when in fact I meant that I’m prone to making mistakes.  ADO.NET requires lots of string-searching for columns and casting those column values to the correct types, and in all of that typing I tend to make more mistakes as opposed to using Entity Framework.