I think my first post will start with some venting so bear with me.
ORM solutions have really made a huge impact on software development with relational databases. It’s pretty much expected from any modern object oriented language to have a built-in ORM solution and/or multiple 3rd party implementations of one.
You could even write a pretty impressive list of benefits of ORMs like productivity, avoidance of vendor lock-in (except DB specific ORMs), and maintenance. But in spite of all this, I do find that ORMs have a very real and prevalent hidden cost:
ORMs set the bar too low for who gets to write data access code
You might have seen this happen, or you may been that person once, but time and again i’ve seen how the lack of understanding of what’s happening “behind the scenes” cause very painful performance, stability, and design issues: 1-n problems, fetching too much data, ignoring batch updates, etc. to name just a few common ones.
ORMs take the discipline of fine-tuned and precise database interaction and takes a huge warm dump on it.
Now don’t be mistaken, the elite can and will use ORMs in the best possible way and in all the right places, but let’s be honest about the majority. I’ve seen the blank stare with eyes glazed when I asked a developer why they wrote 3 nested loops to find a specific value of the child of the child of a mapped ORM entity instead of just writing a specific query for it. Or why they retrieved and iterated over all 5 million items to set the same value of of the same field instead of writing an update statement.
Somehow people assume that writing specific queries for specific cases when using an ORM is an admission of defeat when they can easily just traverse the object graph and call their setters and getters. It all comes crashing down though when you have enough data.
In the end using ORMs properly requires even more knowledge and ability and it should be entrusted to those people who can get it right.
Those of you have passed this hurdle should congratulate yourselves. There aren’t many of you.