Data is in database, mind is in space

Why would you even bother to try to use ORM, when you get whole buckets of haters on the internet. Your architect probably pushes you to do so and you want to be true programmer who does stuff with his bare hands in notepad.

1) You are learning wrong thing.
A lot of people pick up an ORM because they don’t want to take the time to learn the underlying SQL (Structured Query Language).

2) Complex ORM calls can be Inefficient.
Recall that the purpose of an ORM is to take the underlying data stored in a database and map it into an object that we can interact within our application. This often comes with some inefficiencies when we use an ORM to fetch certain data.

3) ORM cannot do everything for you.

Those are points from article: https://blog.logrocket.com/why-you-should-avoid-orms-with-examples-in-node-js-e0baab73fa5

Bonus point for comment, I am going to put it as poster on my wall:

Love the article. I personally prefer NoSQL than relational personally only due to bad experiences from SQL injections.

So fun part is over:

There is introduction spot where layers of abstraction are invoked and that you trade performance for increase in developer productivity. Yes that is true and blanket statements that all ORMs are bad are not productive. It all depends on project and team.

Individuals and interactions over process and tools.

1) That kind of power to pick solution for whole project have only people who are experienced or whole team. Someone picking ORM or SQL only for his side project does not count. Even if you learn something and go working with people who use ORM you learn to use that ORM or find other job. Picking tools for project that someone is paying is not a whim of what someone wants to learn. It is about delivering value.

2) This is even wrong because it reads like somehow magically you don’t have to put your data into objects anymore. I think in the end you will still have to put your data into objects and I bet half of people will do it in inefficient way anyway. They still will not be better than ORM. Then you have second group which will manage to navigate around N+1 queries, tune those joins and guess what, they probably will have to know SQL anyway but they don’t have to write 80% of easy SQL, they just use their SQL-fu for places where it is needed.

3) That is such no argument, especially when author himself notes that ORMs have in their interfaces methods to just run query. You should avoid using cars because they don’t fly and sometimes they crash into things. (crashing part is saying more about drivers than cars itself)

Unfortunately I am spoiled kid of Entity Framework. Strongly typed C# and built in database migrations that keep my schema in synch with all queries and objects is something hard to beat for ease and speed of development. I don’t have to track what kind of changes to schema someone else from team did. If they did something wrong I get it in compile time. Maybe on dynamic languages ORMs are not useful and they should use noSQL.