Thanks, Konrad. I'd be happy to.

I suppose that the issue is technically due to the combination of application frameworks like the Entity Framework and their ORMs.

Let's take the case of the get/read anti-pattern that arises in most (all?) such combinations.

The introduction to each framework + ORM typically features a simple GetById example (GET /items/{item_id}), which involves creating a database table, a class (or model) representing the entity or RESTful resource to be retrieved, a repository, and a controller.

Some frameworks automate or hide all this code, but it's a fair amount of code to be created and maintained just to get a single item from the database.

Soon we realize that we also want the ability to get items by name and by other attributes they possess. And every one of these separate get methods spawns at least its own controller, although in many cases model variants are introduced in order to "simplify" the code.

Meanwhile on the SQL side, any and all of these gets can be performed with a properly parameterized SELECT statement, including pagination and other more advanced features.

So why lead developers down the path of creating and maintaining all that statically-defined code bloat and promoting this methodology as "The Way"?

And I haven't even touched on all the various rules that frameworks and their ORMs try to enforce by default: attribute naming, case, punctuation, default vs automatically assigned vs required values, validation, etc.

Moreover, more and more of the data processing that should be done on the database server is being done on the application server.

There are very lightweight ways to do all this better by simply using the tools as they were originally intended and stripping away most (all?) of the opaque, bloated abstraction layers.

This is just a start, but I hope that it begins to illustrate what I see as the problem.