Comment by lelanthran

I do line of business apps right now.

It seems to me that we have the abstraction inverted when it comes to ORMs, which is why so many experienced devs dont like ORMs (but can't really articulate why).

Here's my take, in the context of business logic:

The schema represents the business rules. The ORM papers over the DB so that the code doesn't have to match the business rules. Then the dev implements those rules again in code, but poorly.

If you simply skip the programming language using something like Postgrest you end up with a declarative structure of the business rules.

The first problem is that most developers would rather hunt a bug or perform a modification on a 30k Java or C# or python or ruby program than in 5k of SQL.

The next problem is that tooling for SQL is crap. It's declarative so good luck stepping through the logic. The dialects are all different so editors aren't great at spotting errors.

The last major problem is that changing it is hard - you can't simply change the schema and redeploy because migrations have to be made on the existing data.

All of these are surmountable in some ways, but they certainly ain't easy.

Doing LoB apps have opened my eyes a lot: maybe 99% of logic is shorter when expressed in SQL. Of course, that means that the only use of an ORM in this case is connecting to the DB, sending the query, and sending back results.