IMO no ORM. I've only had issues with ORMs. They work okay-ish in the very bare-bones usecases, like inserting one record into one table or fetching one record. After that, their semantics just impede your velocity.
You can represent really, really complex data retrieval and consolidation semantics in SQL. ORMs are really more of an organizational tool in my mind.
I just throw all the SQL functions into a repository class around one "thing". Not even object, it can be related functionality or operations.
SQL in code can be awful, if spread out across your codebase. So I think just don't do that.
We have a monolith that gets maybe ~1000 commits a day. We don't use an ORM, just SQL and query builders. It works out if you have good modularization.
What's a better ORM in terms of productivity and ergonomics?
IMO no ORM. I've only had issues with ORMs. They work okay-ish in the very bare-bones usecases, like inserting one record into one table or fetching one record. After that, their semantics just impede your velocity.
You can represent really, really complex data retrieval and consolidation semantics in SQL. ORMs are really more of an organizational tool in my mind.
I just throw all the SQL functions into a repository class around one "thing". Not even object, it can be related functionality or operations.
SQL in code can be awful, if spread out across your codebase. So I think just don't do that.
We have a monolith that gets maybe ~1000 commits a day. We don't use an ORM, just SQL and query builders. It works out if you have good modularization.