Why avoid an ORM - /dev/solita
I happened to discourage using an ORM in our company internal Slack and suddenly found myself needing to explain some problems common in ORMs. I got a little bit carried away, and the explanation turned into this blog post.
First of all, what counts as an ORM? This is just as difficult to answer as “what counts as an object-oriented language” or “what counts as agile”. There exists no single widely accepted definitions for these things since they are more like paradigms: a specific paradigm is usually related to certain kinds of aspects, and it makes using certain design choices more natural than others.
For example, in an object-oriented language, it’s often natural to encapsulate (mutable) state inside a structure, whereas in a functional language it’s often natural to solve the same problems by moving (immutable) state outside the structure to the edges of the system. While Java is widely considered an object-oriented language, one can still do functional programming in it. On the other hand, lambda calculus can be used to model objects and encapsulation, but it’s certainly not what most people would call an object-oriented language.
N+1 queries, object identity and managing object relationships are concepts or problems that tend to come up with ORMs. Just because a tool makes these problems possible does not yet make it an ORM, but certainly closer to being an ORM.
