I stuck to DB-First model + LINQ + SaveChanges() and largely managed to keep out the magic quite successfully for a .NET6 web project last year. Records are fantastic when composing queries. I didn't touch inheritance or any fancy mapping strategies -- one table, one class.

The only bit of framework-specific / hidden magic debugging I really had to do was the realization of AsSplitQuery() when creating objects composed of independent datasets, AsNoTracking() for a decent perf bump, and single group-by's are fine but when you start nesting them it gets really hairy really quickly -- they usually ended up becoming views.

Otherwise change-tracking worked wonderfully for batch-updating (but everything I did was short-lived) and outside of group-bys, the LINQ -> SQL mapping (and vice-versa) was extremely predictable, in both EF Core generating the SQL I expected, and creating the correct LINQ from the SQL I knew I wanted.

9/10 would use again; inline sql is for nerds

What is DB-First model ?

There was a specific feature in the .Net Framework version of EF called “database first” that would analyze your existing database and generate an xml file describing it that EF would use to generate models on the fly. It was pretty horrible and thankfully isn’t supported by modern EF Core. However the term database first stuck and it’s really come to refer to any any scenario where you manage your database using a tool other than Entity Framework migrations. Could be a dedicated migration tool, Sql Server database project, whatever. Then you either create EF models to match the tables or use a tool to generate them.

Yeah, if you stick to a very narrow subset of what it can do then you will have no problems. Hopefully everyone else on your project is on the same page about what that subset is.

I mean if your alternative is no-orm, inline SQL, then the “narrow subset” I’ve chosen is precisely competitive, and is highly effective, and IMO strictly an improvement. If your alternative is a different ORM, then my opinion is moot, but at least I’ve never seen an ORM be worth the headache (which is why we avoiding using the full feature-set in the first place)

I don’t know why one would have an issue with not using the features they’re not looking for anyways. Keeping everyone aligned on patterns/usage is half the point of code review, and it was managed there without much trouble (you can’t really do the truly magical incantations without quite a bit of setup)

I’m a fan of Dapper for doing the tedious mapping and result set handling stuff but still sticking to SQL. I don’t really find writing LINQ instead of simple SQL queries is much of a time saver.

I'm not a fan of the LINQ syntax itself so much as the fact that I'm not longer dealing with arbitrary strings being smashed together that happen to form a valid SQL statement, and all the benefits that inevitably come with not having stringly-typed logic (like being able to refactor properly, type safety, proper autocomplete, no-typos-at-runtime, etc). It maps closely enough to SQL itself that the negatives of having to use an "intermediate" language/api aren't significant, and the magic can be made negligible, so it's largely pure gains.

The tools are good enough that my IDE can detect SQL strings and offer suggestions, plus once the database starts getting used by multiple applications even type safety won’t really make it safe to go renaming existing columns.