ORM is an anti-pattern
Here we go again.  I'm pretty sure I've seen this post here (and the famous Vietnam of Computer Science one) several times before.<p>No database access abstraction is going to be great for all situations.  Whether it's object-oriented, functional, or DSL-based, there are going to be situations where it's frustrating to use.  However, each of these abstractions have a purpose and a clear benefit for a certain subset of situations, or else they likely wouldn't have been created.<p>Since people find some abstractions useful for some subset of situations, why waste so much time and energy fighting against its use entirely--labeling it an "anti-pattern"?  On the other hand, why waste time and energy arguing for its ubiquitous use?  Like with all other technology choices, the right prescription is to use an abstraction when it makes sense, and to abandon it when it does not.<p>Maybe it would be more constructive to frame the discussion in this way: what cases are ORMs useful for, and what cases are they bad at?  How can we identify the good use cases from the bad?  Which use cases seem to be good uses but turn out to be bad, and why?  What are alternative solutions for those bad use cases?  Are there different philosophies of ORMs with different tradeoffs?  What are those philosophies and tradeoffs and how can we choose which one most suits our problem?