I Would Never Use an ORM, by Matteo Collina

What's an ORM? An Object-Relational Mapping tool (ORM) is a library for mapping a SQL table to a Class. In most cases, ORMs force the users to structure their code to have Model objects that include both data access and business logic.

Once upon a time, I did several projects using ORMs, as I followed the common belief that they would simplify the development and maintenance of projects. I was wrong. ORMs are often a hurdle to overcome for the most complex part of a project.

As the next stop of my journey, I recommended people use the native languages of their databases, e.g., SQL. This works great for the most part, but it creates quite a struggle: there is a lot of boilerplate code to write that can be quite tedious. I was wrong, again.

Today I'm presenting you something new.

Speaker: Matteo Collina,
Co-Founder & CTO at Platformatic

#JavaScriptDay2022

–––

🔗 Browse our resources 🔗

Check out WebStorm, a JavaScript IDE by JetBrains, and get a 30-day free trial:

⭐️ Keep in touch ⭐️

JetBrains on Twitter:

WebStorm on Twitter:

[johnwales]

For projects where the biggest concern is not squeezing every ounce of performance out of every thing you do. ORM for me offers more pros than cons. And you can still write raw parameterised queries for more complex queries.

[ParkImaging]

You lost me at "never". No reason to start what should've been an open-minded discussion with a dogmatic statement. I prefer a pragmatic approach to building large systems and leave out "never" from the discussion.

[FooCo]

2min in, why orm is bad:
- you are not able to handle 2000 models
- there is no place to put the business logic but controller or model
- orm code results in spaghetti code - always

complete unrealistic and false assumptions

[flogginga_dead_horse]

Won't use an ORM but writes backend code in JS. Close video. ;)

[Thristle]

Never use an ORM unless it's *my* ORM

[onyilimba]

I kept trying to understand what he's talking about, I kept loosing his point every 30 seconds.

[AlexandruBusuioc]

You would never use an ORM... in JavaScript? Why are you using JavaScript for backend anyway?

[marco.garofalo]

The argument against MVC is very fuzzy, people keep misunderstanding MVC all the time, the latter is a delivery mechanism, the "M" in MVC is not a domain model, nor a persistence model, is a presentational/transport layer model, so it has nothing to do with the database.
Also what does it mean to have only 3 places to write the code, and the 2000 models argument? In a clean architecture, that promotes separation of concerns, the MVC pattern would be something applied at the infrastructure layer, the business logic would go in the domain which, obviously, is unaware of delivery and persistence mechanisms.
The argument around a huge explosion of models is also a bit unrealistic, let's assume we have a traditional CRUD set of operations per resource we would have: C using 2 models (request and response payloads), R using 1 model (response payload), U using 2 models (request and response payloads) and D using no model, so saying we will soon have 2000 models will translate into managing around 200 resources, something that IMHO does not fit well in a single application, is now a huge monolith with 200 reasons to keep changing.

[PiletskayaV]

2000 models is 2000 tables in a database. Let's do it without ORM and define 2000*x functions for managin those tables where x is all necessary operations like add row, read, update etc.
If you have 2000 models in your project it is not an ORM's problem. It's a problem of a dev who can not build a good architecture for his project.

Also... building backend in js? I would question this part of a video rather then any ORM related issues.

This video is some kind of an out-of-season april fools joke I guess.

[muharief]

I would never use javascript for backend.

[georgeFulgeanu]

This guy is definitely a genius, the way in which he proves that ORM is bad is horrible. Like I haven't seen so many bad arguments in the same place. Not only is he USING an ORM he wrote a code generation framework in which based on the table structure it generates CRUD for each db, which is a bit bad to expose everything and not having the possibility to alter the code inside. The JS community still has decades to catch up to mature ecosystems like C#, Java, Python, PHP.

Side note: we also avoid ORMs when we need to make sure performance is the most important factor, which rarely is but that's another discussion.

[lamkask]

For me at least, the main advantage of using ORM is that the data you work with has a fixed structure. This is very useful especially on huge projects where there is no chance of remembering all of the data structures. It is probably not a problem in statically typed languages, but for example in PHP, ORM helps you not waste time searching for what properties arrays contain.
Another useful thing is abstraction on top of your database. Yes, you can use views, but they are not a perfect solution for everything, especially if they call procedures. Databases are a hell to debug.

[maksymkhartanovych]

Not all ORMs are anti pattern :) Modern Data mapper ORMs are live well together with DDD and CQRS/ES and help you model your domain as plain objects by decoupling the mapping and persistence logic to infra/framework config level

[JagdeepSinghKalsi]

Did not expect such a video on JetbrainsTV.
Have high expectations. Got a bad idea implemented in probably the worst possible manner.

This was a promotional content, at best.

TBH, I am short on words to express the concerns and disappointments that I have from this video.

[ПожилойСкарабей]

I Would Never Use an ORM -> Proceeds to use his ORM which abstracts generation of GraphQL and Rest endpoints in itself, yay!

[jovincebrillantes]

Laravel's ORM is pretty sick though

[GolderiQ]

I was actually agree with him on the problem, but then he shows his solution and lost me. I mean did he heard about postgREST, which create a REST API on top of your tables, or Supabase an open source alternative to Firebase that leverage postgREST, GraphQL, and many other tools to go even further?

[queiroz-rafael]

yes, me too. Important to know them for enhancing existing apps that already use it. But my own projects - no ORM: lighter and faster. Who understands SQL and DAO pattern may build clean solutions. That is my POV.

[esra_erimez]

ORM came out of a long time of searching for solutions to the Object to Database problem. There were many solutions proposed. Some include things like "Pointer swizzling", "Texas: An efficient, portable persistent store", "InterSystems Caché" just to name a few. Over time, ORM won out. I think a salient point that is left out of conversations criticizing ORM is that is not necessarily a one to one mapping of classes to tables. ORM can represent all relational model entities such as views and stored procedures. ORM gives a convenient entry to the relational model.

[pm]

I'm absolutely not a fan of ORMs.
Setting aside that I once wasted a lot of time on the futile task of generalizing storing objects in relational databases, I'd still recommend heavily against using them.
You're talking to a relational database (in the common case) and you need to understand how it works, so you need to be able to reason about SQL anyway. Once you can that, you can reason about most SQL.
ORMs have the same issues as using too much syntactic sugar. It hides complexity you need to understand anyway and thus makes it a lot harder to reason about it when the underlying reality peaks through (and it will). On top of that it also takes away your ability to reason about the SQL for code new to you, since the way the ORM api works and hides the SQL is different from language to language and ORM library to ORM library.
So when I, say, am thrown into a PHP code base using "Parable", it doesn't help me much understand it that I'm perfectly fluent in MySQL or some other ORM.

Don't use ORMs. ... learn SQL instead.