| ▲ | vjerancrnjak 3 hours ago | |||||||||||||||||||||||||
OOP is not simplifying CRUD or DB ops because you want to batch. You don’t want lazy loading. You don’t want to load 1 thing. You don’t want to update 1 thing. You want to actually exploit RETURNING and not have the transaction fail on a single element in batch. If you care about performance you do not want ORM at all. You want to load the response buffer and not hydrate objects. If you ignore ORM you will realize CRUD is easy. You could even batch the actual HTTP requests instead of processing them 1 by 1. Try to do that with a bunch of objects. I would personally never use ORM or dependency injection (toposort+annotations). Both approaches in my opinion do not solve hard problems and in most cases you don’t even want to have the problems they solve. | ||||||||||||||||||||||||||
| ▲ | sroerick 3 hours ago | parent [-] | |||||||||||||||||||||||||
I agree with you, but I am not sold on optimizing for performance above all else. Business logic ran fine on ancient mainframes. It can run fine on Raspberry Pis. CRUD is super easy. It's also not super resource intensive. I know that's the path that led us all down into Java OOP / start menu is a react native component, but it is actually true. ORM adds a convenience layer. It also adds some decent protection against SQL injects OOTB and other dev comforts. Is that trade off worth it? Probably not. But sometimes it's the best tool for the job | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||