4 ms·
> Well the problem is, if you don't use an ORM, you'll invent one yourself...only poorly There is always a trade-off. The code you wrote, even if it is poorly
by noncoml 9y ago
> Well the problem is, if you don't use an ORM, you'll invent one yourself...only poorly
There is always a trade-off. The code you wrote, even if it is poorly re-implentation, you know it inside out, since you wrote it. The third party code, may be better, but people usually make a lot of implicit assumptions and end up not using it correctly, so you end up in situations like this.
For DB layer, I usually prefer custom code so I know exactly what is going on under the hood.
- jaggederest 9y agoThe best of both worlds is just to... actually understand the ORM you choose to use. I'm always confused by how reluctant folks are, in general, to read underlying libraries.
- Can_Not 9y agoYou don't even have to read the library source, just verify the SQL statements generated. Most ORMs let you drop into raw SQL for advanced clauses and sub-statements. For me there value of an ORM is composable business logic. For example, if whereHasLotsOfTrees is a complicated SQL subquery and has it's business logic definition changed, I can edit only one function and have the new logic work everywhere.