ive been using EF Core for ORM and this hasn't really been a problem for me or any of my colleagues for at least a decade because we don't use lazy loading. database calls are explicit; mapping the results to objects is implicit. is everyone outside of .net still banging their heads against stuff like this?
It's great for small queries and small data sets, but look up Cartesian explosion and also review the generated SQL when using .Include(). You'd be surprised at what gets generated and how quickly performance can degrade as the result set grows
Cartesian explosion in EF can be mitigated by either adding .AsSplitQuery() to the queries where necessary, or by specifying it as the global default during context setup.
Yeah, it's still something you need to be aware of and correctly mentally model, though. And if you don't, or if your colleague doesn't even know about it, well, then it bites you in the ass.
Yeah, I make sure to watch out for that. I've made some massive cartesian explosions in my day for sure. There are some occasions where AsSplitQuery() is inescapable or you just break those queries out to raw sql.
if you are dealing with a lot of 1:1 entities, it works fantastic.
Something I've been looking into adding to one of our projects is updating our E2E snapshot tests — which as of now records all external requests as well as Activity (OpenTelemetry) happenings so I can see what's going on — to also log all SQL queries so we can see clear regressions in SQL queries.
My main blocker right now is the fact that if you have multiple inserts in one EF Core LINQ query then it generates a (documented) random ordering of the inserts, so the snapshots never match.
93
u/archipeepees 8d ago
ive been using EF Core for ORM and this hasn't really been a problem for me or any of my colleagues for at least a decade because we don't use lazy loading. database calls are explicit; mapping the results to objects is implicit. is everyone outside of .net still banging their heads against stuff like this?