4 ms·
I've certainly fallen in to the anti-ORM camp, because I know SQL well and at least like to think I can put together a schema better than any ORM can. (I usuall
by Xophmeister 6y ago
I've certainly fallen in to the anti-ORM camp, because I know SQL well and at least like to think I can put together a schema better than any ORM can. (I usually can.) However, then my code becomes tightly coupled to the schema, despite my abstractions, which makes it harder to change and basically impossible to unit test.
- arcturus17 6y agoWhat do you end up doing, then?
- Xophmeister 6y agoHope I get it right (or right enough) first time an then worry about how I'm going to set up integration testing for this "thing" :P
- wegs 6y agoI make my own abstractions. I might have a file called 'kvs' which implements a key-value-store abstraction, or one called 'friendnet' which implements a graph of social relations. * Those files have all the SQL. I never have raw SQL in my main application. * Those files never e.g. call into my web framework, have HTML, or otherwise. They're a stand-along abstraction. An ORM mutates a good abstraction (SQL) into a not-as-good one. Making a generic abstraction which works everywhere is hard, and SQL is the best one we've got. By making it domain-specific, we can mutate it into a good one. One of the key principles I use is to try to have more than one back-end. For some (like a kvs), that might be Elasticache AND in-memory AND postgres. For something relational, it might be postgres and sqlite.