3 ms·
Seems like there's 3 groups of opinions on ORMs: Firstly (1); "I want to use the ORM for everything (table definitions, indexes, and queries)" Then second (2)
by zknill 3y ago
Seems like there's 3 groups of opinions on ORMs:
Firstly (1); "I want to use the ORM for everything (table definitions, indexes, and queries)"
Then second (2), on the other extreme: "I don't want an ORM, I want to do everything myself, all the SQL and reading the data into objects".
Then thirdly (3) the middle ground: "I want the ORM to do the boring reading/writing data between the database and the code's objects".
The problem with ORMs is that they are often designed to do number 1, and are used to do number 3. This means there's often 'magic' in the ORM, when really all someone wanted to do was generate the code to read/write data from the database. In my experience this pushes engineers to adopt number 2.
I'm a big fan of projects like sqlc[1] which will take SQL that you write, and generate the code for reading/writing that data/objects into and out of the database. It gives you number 3 without any of the magic from number 1.
[1] https://sqlc.dev/ https://sqlc.dev/
- karmakaze 3y agoMaybe those are the main/popular groupings. Where I fall is that I want typesafe constructions of queries that match the current schema. The query compositions should follow the SQL-style structure so there's no 'shape-mismatch' composing the query using the library. Some may not consider this to be an ORM (though it does map relations to objects).
- waffletower 3y agoThere is definitely a fourth category -- "I want to build database queries natively using the paradigms of the language I am developing with, without use of SQL or an intermediary which translates into SQL."
- tracker1 3y agoI'm pretty firmly in #2... it's relatively straight forward in a scripting language, and easy enough with something like C# with Dapper. In the end ORMs tend to over-consume, and often poorly. And even when they don't in most cases, they start to in more difficult cases. That doesn't even get into the amount of boilerplate for ORMs. You have to buy in to far more than their query model(s).
- tantaman 3y agoI'm in a 4th camp: we should be writing our applications against a relational data model and _not_ marshaling query results into and out of Objects at all. Elaborations on this approach: - https://news.ycombinator.com/item?id=34948816 https://news.ycombinator.com/item?id=34948816 - https://github.com/papers-we-love/papers-we-love/blob/main/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/main/d... - https://riffle.systems/essays/prelude/ https://riffle.systems/essays/prelude/
- pjmlp 3y agoStill on the 4th camp? Using stored procedures and triggers as much as possible.
- specialist 3y agoNice share, thanks. I was never more productive than when using Access (and dBase II before that). Why can't we have that? My theory: Something was lost in the jump from workgroup computing to client/server. Imagine if Access was rebuilt on top of a client/server stack. That's kind of what Riffle is trying to do. I've been (slowly) working on the persistence stuff. It (mostly) moots the SQL vs ORM vs query builder slap-fight. I've got some notions (and POCs) about UI, mediated via HTTP & HTML. I'd love to have some CRDT-like smarts; learning more is on my TODO list. I'm still thinking about the "reactive" part. I haven't imagined anything past Access VBA style programming. I'm struggling to envision a FRP-meets-CRUD future perfect world.
- tantaman 3y ago> I was never more productive than when using Access (and dBase II before that). I've never used access and have 0 familiarity with it. Are there any examples I could look at?
- sanderjd 3y agoWell put!
- specialist 3y ago> ...this pushes engineers to adopt number 2 Yup. Use of HQL/JPQL is proof that you shouldn't be using an ORM. Just use SQL instead. And once you have some SQL, it's just easier (overall) to do all SQL.