Hacker News Reader

Comment by rowls66 | Hacker News Reader

I would say that ORM's are an anti-pattern.

Do you have any proof ?

As a rule of thumb, I avoid using the word "proof" in this way. Proof is great as a mathematical noun, a publishing noun, or a baking verb. What you're asking for, based on your use of "any proof" is better encapsulated in the word "evidence". Evidence accumulates. Often encapsulated in units called "exhibits". Given some test, if greater than 50% of the evidence leans one way, then you have a preponderance of the evidence. If 75% leans that way, the evidence is "clear and convincing". If 99% leans one way, the evidence is "beyond a reasonable doubt".

In this case, we'd start with the test. From Wikipedia, "An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive."

Then we look at the top answer on Stack Overflow (2)

=== Exhibit A ===

  But ORM can be a pain:

    You have to learn it, and ORM libraries are not lightweight tools;
    You have to set it up. Same problem.
    Performance is OK for usual queries, but a SQL master will always do better with his own SQL for big projects.
    It abstracts the DB. While it's OK if you know what's happening behind the scene, it's a trap for new programmers that can write very greedy statements, like a heavy hit in a for loop.

=== Exhibit B ===

  Do not try to write your own ORM, unless you are trying to learn something. This is a gigantic piece of work, and the old ones took a lot of time and work before they became reliable.

So, I have presented some initial evidence that tends to support the idea that an ORM is an anti-pattern. If you disagree, you are welcome to cite additional evidence to the contrary. But keep in mind the test elements.

I don't consider "learn something" is anti-pattern. It depends on quality of the library itself to know if it's worth learning.

Setting something up is similar. It depends on complexity of toolings.

Performance is also dependant on the quality of the generated native query.

It abstracts the DB, which i consider a good thing in long term, and of course, some ORM gives you enough escape hatches in a good way.

Overall, i love working with a "good" ORM rather than working directly with SQL (for example).

But the real world libraries is not good enough for the ORM ecosystem to have good faith on DX side.

ORM allows you to get away from writing stringly typed SQL and use correct types instead - reduces amount of boring mistakes

ORM allows you to focus more on modeling domain model instead of db model

ORM speeds up writing boring queries like insert or update

ORM can detect changes and update stuff accordingly

ORM prevents people from SQL Injections

ORM can manage migrations and db schema versioning

ORM allows you to change DBs to some extent easier

ORM still allows you to write raw query when you need it

Try C#s EF Core with LINQ.

I would suggest looking at jooq. It's a great orm.

I think JOOQ isn't a proper ORM, but it is splitting hairs on the definition. It calls itself an OOQ (object oriented querying)

ORMs become an antipattern when they try to abstract away the database completely by masking write operations and paging lists implicitly. Developers need to know precisely when these operations happen to manage performance.

JOOQ doesn't do that. Active record does. Hibernate does (but it's configurable)

I agree that jooq isn't a typical ORM. MyBatis is in the same camp. I really can't believe it took so long for people to realize old-school ORM solutions like Active Record and Hibernate were bad ideas. I cringe whenever I come across Hibernate code.

The "object oriented" in jOOQ Object Oriented Querying stands for an object oriented query model, not mapping to object oriented target data structures.

Reply on news.ycombinator.com