[denismenace]

Why is EF regarded as such a good ORM? I've encountered countless bugs in different repos related to its stateful nature after many years in .NET. Personally I found it completely illogical for my ORM to maintain state. I just want it to hold my schema and build queries.

[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.

[achandlerwhite]

EF or EFCore? Specifically EFCore is highly regarded whereas legacy EF not so much.

[wvenable]

EF Core is amazing -- in it's default setup it works for 99% of situation. For the 1%, you can basically turn off everything you don't want.

[arwhatever]

EF hits you in the face right at the start with the massive convenience that it provides. And then the paper cuts start adding up, and adding up, and adding up.

Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.

[neonsunset]

What papercuts?

[arwhatever]

Being forced to compromise your domain model. Yes the product has improved this greatly in recent years but it’s still inadequate IMO.

Fluent syntax can at first seem like the product has achieved persistence ignorance nirvana but then you have to compromise a little here, compromise a little there, until some point, if you’re still thinking critically about the design, you realize that you’re writing your app in Entity Framework as much as you are writing it in C#, as I mentioned.

Passing around a large mutable blob (dbcontext) which, if not managed with the utmost discipline by your dev team, can make it necessary to understand what large swaths of the code do before you can adequately understand what any small part of the code does.