3 ms·
Not all ORMs are like hibernate and gorm. I'm author of a lightweight ORM for Go and Scylla / Cassandra [1] so I may be biased. In my view use of a good ORM ma
by mmatczuk 6y ago
Not all ORMs are like hibernate and gorm.
I'm author of a lightweight ORM for Go and Scylla / Cassandra [1] so I may be biased.
In my view use of a good ORM makes your code more resilient to change, refactorings are simple and stupid mistakes largely eliminated.
A benchmark of usefulness of an ORM can be how many lines need to be changed to add a new field to a struct / class.
In a good ORM this should be about 1, it should still work be ~1 if you use a hand crafted SQL / CQL.
The worst thing that ORMs try to do is handling relations (eager / lazy loading) and handling sessions / object lifetime. This is mainly because it's impossible to have one-fit-all solution for all usecases even in one application.
[1] https://github.com/scylladb/gocqlx https://github.com/scylladb/gocqlx
- scaryclam 6y agoI use a lot of raw sql and I also use ORMs. I don't see ORMs as being the issue the author thinks it is, bit rather that developers suck at designing the data layer. A half decent design will do as you say; it will allow the use of an ORM or hand written sql. ORMs make magic easier, and pulling that magic apart is a real pain, but so is working with triggers and stored procs. The problem exists on both sides. The solution isn't to get rid of ORMs, but to train developers in better system design.
- PeterCorless 6y agoAll reminds me of this talk at Aerospike back in 2015: https://twitter.com/i/events/1032400612653129729 https://twitter.com/i/events/1032400612653129729
- PeterCorless 6y agoMy favorite quote of the talk, "There's a lot of stuff that's deployed everywhere that sucks everywhere."