6 ms·

I never understood the love for them. I recently posted this about my experience in migrating to PostgreSQL without anything of the sort of ORM... https://henv

by henvic 5y ago

I never understood the love for them. I recently posted this about my experience in migrating to PostgreSQL without anything of the sort of ORM... https://henvic.dev/posts/go-postgres/ https://henvic.dev/posts/go-postgres/ We achieved a really great result doing so. In comparison, at my previous workplace, I was forced to use ORM, and everything was slower, awful, and hard to maintain for no benefit whatsoever. I'm not saying that it's 100% fault of ORMs, but at least 60%, for sure it was.

Daishiman 5y ago
The love comes when you're a single maintainer at a standard line-of-business app that manages a few hundred tables. Most apps don't need to be performant. Most business logic is object-centric and relation-centric. Leveraging the best features of highly-integrated frameworks like Django and Rails mean that the framework has to understand and talk to objects, not database rows. I have maintained several Django projects with a couple hundred tables by myself or another team member. I cannot imagine maintaining such a gigantic heap of equivalent SQL for trivial business logic.
hello_moto 5y ago
Nobody "loves" them. It's one of many tools just like generic, OOP, functional, imperative, "nullsafe" features. Long list of tools with usefulness. I find people who tend to develop extreme on either end aren't that pragmatic. I read your blog and I don't see any problems caused by ORM. Your product data model should fit in ORM (I get it, you're just using it as a simple example). The blog only mentioned "I used ORM in the past and had bad experience" without explaining the problems. > In comparison, at my previous workplace, I was forced to use ORM, and everything was slower, awful, and hard to maintain for no benefit whatsoever That seems to be the problem: your previous workplace, not the ORM itself.

by henvic 5y ago

Daishiman 5y ago

The love comes when you're a single maintainer at a standard line-of-business app that manages a few hundred tables. Most apps don't need to be performant. Most business logic is object-centric and relation-centric. Leveraging the best features of highly-integrated frameworks like Django and Rails mean that the framework has to understand and talk to objects, not database rows. I have maintained several Django projects with a couple hundred tables by myself or another team member. I cannot imagine maintaining such a gigantic heap of equivalent SQL for trivial business logic.

hello_moto 5y ago

Nobody "loves" them. It's one of many tools just like generic, OOP, functional, imperative, "nullsafe" features. Long list of tools with usefulness. I find people who tend to develop extreme on either end aren't that pragmatic. I read your blog and I don't see any problems caused by ORM. Your product data model should fit in ORM (I get it, you're just using it as a simple example). The blog only mentioned "I used ORM in the past and had bad experience" without explaining the problems. > In comparison, at my previous workplace, I was forced to use ORM, and everything was slower, awful, and hard to maintain for no benefit whatsoever That seems to be the problem: your previous workplace, not the ORM itself.