[htgb]

Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.

Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:

- Convenient definition of schema.

- Nice handling of migrations.

- LINQ integration

- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.

What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?

[snarfy]

Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.

The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.

[htgb]

Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.

And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.