But ORM's don't actually help for the trivial queries.
I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill.
As for the common joins, in my experience they rarely are that trivial. Sometimes it's a left join, sometimes an inner join. Sometimes there's a limit or not. Sometimes there's an aggregate function.
If you find yourself writing the same query structure 20 times, then create a function for it. But I've never found that to be the case in projects I work on.
I just personally find that ORM's are total overkill in the situations where they can be usefully applied. So the disdain for them kind of makes sense.
> I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill.
Making a homebrew data layer isn't avoiding an ORM, it's building one.
> If you find yourself writing the same query structure 20 times, then create a function for it.
What do you think ORM's do? That is what they do, they provide a standard API for all the common queries.
No, ORM's provide object-relational mapping, and all sorts of functions for building up queries as part of that. They don't provide an API for common queries at all. I don't even know what "all the common queries" would be... beyond get-a-value-for-pkey, every app is totally different in the kinds of queries it needs.
What I described isn't a homebrew data layer or building an ORM, it's just a few helpful shortcut functions for queries.
> every app is totally different in the kinds of queries it needs
There is more to SQL than queries. Every app need insert, updat, and delete, and a basic select 1 and select many matching a predicate. Those can all be automated; that's what ORM's do, they automate the repetitive simple stuff.
More complex queries that strain the ORM's abilities can be done in SQL in a view, and then mapped in by querying the view with the ORM. Or you can just drop into raw SQL when necessary. Every app is not different, they are largely all very similar.
I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill.
As for the common joins, in my experience they rarely are that trivial. Sometimes it's a left join, sometimes an inner join. Sometimes there's a limit or not. Sometimes there's an aggregate function.
If you find yourself writing the same query structure 20 times, then create a function for it. But I've never found that to be the case in projects I work on.
I just personally find that ORM's are total overkill in the situations where they can be usefully applied. So the disdain for them kind of makes sense.