[ochoseis]

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.

[neonsunset]

One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).

I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.

[seabrookmx]

I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.

[neonsunset]

Dapper is great. I'm very happy that there now exists an AOT-supporting flavour of it too: https://aot.dapperlib.dev/

As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.

[seabrookmx]

So common that apps like sentry have special logic to detect these "N+1" queries. We find DRF is awful for this.