> Entity Framework on .NET is amazing.

I disagree. It is probably one of the less terrible ORMs, but it is far from amazing. The object-relational impedance mismatch will always dominate for anything that isn't trivial business. EF works great until you need different views of the model. It does support some kind of view mapping technique, but it's so much boilerplate I fail to see the point.

Dapper + SqlConnection is goldilocks once you get into the nasty edges. Being able to query a result set that always exactly matches your view models is pretty amazing. The idea of the program automagically upgrading and migrating the schemas is something that was interesting to me until I saw what you could accomplish with Visual Studio's SQL Compare tool & RedGate's equivalent. I feel a lot more comfortable running manual schema migrations when working with hosted SQL providers.

> It does support some kind of view mapping technique

Can you call .Select(entity => SomeSmallerModel() { Name = entity.Name }) or something like that to select what you need? If I am understanding your issue correctly.

I also agree that its one of the least worst but there are still things that annoy me.

> I feel a lot more comfortable running manual schema migrations

Me too. I use a DB-first approach. Then EF simply rebuilds the application models automatically with a single command.

> EF works great until you need different views of the model

You can easily project or use views with SQL then projected onto objects. It's very convenient with `.FromSql`:

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

Doesn’t entity framework have a huge memory footprint too?

If you don't do stupid things like requesting everything from the database and then filtering data client side, then no.

We have one application built on .NET 8 (and contemporary EF) with about 2000 tables, and its memory usage is okay. The one problem it has is startup time: EF takes about a minute of 100% CPU load to initialize on every application restart, before it passes execution to the rest of your program. Maybe it is solvable, maybe not, I haven't yet had the time to look into it.

Yeah makes sense. I should have used my language more carefully: I have very little hands-on experience with entity framework, and thus don’t have objective reasons to say it has a “huge” memory footprint.

Does the startup time/CPU usage cost vary depending on the size of the dataset you’re interacting with?

Hmm, it should not be taking this much time unless you're running into an edge case - we have a fairly complex application that needs to pre-load a lot of data from persistence (no EFC though, it's an embedded DB) and over the wire at startup, and it still takes 15 seconds on a rainy day, mostly waiting for requests to finish. If you can gather a profile it will likely shed some light on why this takes place. Worst case, if you have a repro, it's worth to file an issue at https://github.com/dotnet/efcore. When you have time that is.

Do you have any links that note memory usage issues with any of the semi-recent EF Core versions?

No. To be clear: I wasn’t trying to say it was bad. Just repeating what I had read in a (fairly old) .net book. Should have chosen my words more carefully.

To be fair, old Entity Framework was on the heavier side. Still much faster than e.g. ActiveRecord but enough for Dapper to be made back then. The gap between them is mostly gone nowadays plus .NET itself has become massively faster and alternate more efficient alternatives got introduced since (Dapper AOT, its main goal is NAOT compatibility but it also uses the opportunity to further streamline the implementation).

Thanks for the context. I’m new to the ecosystem, so it’s valuable to hear thoughts like these from people with more experience with it.