7 ms·
You can quickly get a database spun up, but that time is offset by many of the warts that you'll run into later on. For example, you'll quickly realize you nee
by pknopf 8y ago
You can quickly get a database spun up, but that time is offset by many of the warts that you'll run into later on.
For example, you'll quickly realize you need to have ```AsNoTracking``` on your queries because the performance is terrible.
You'll also find that you can batch update/delete items.
I've also had problems with migrations after updating EF Core (don't remember exactly).
You can get spun up quickly, with Linq, using something like Dapper or ServiceStack.OrmLite. They work on raw ADO.NET, so they are incredibly easy to reason/work with. The errors that you'd run into wont be shrouded in layers/abstractions that are specific to EF/Core.
- JamesBarney 8y agoI definitely think you're right that as ORMs move farther away from the bare SQL abstractions leak and when things break they break in bizarre hard to grok ways. But I also think that heavier duty ORMs have their place. Recent circumstances have meant that I'm building out a lot of applications from start to finish in one to three weeks. These applications deal with very little data, the largest tables are in the 1000's of records and in circumstances like that I need crank developer productivity to 11 and for that I'm willing to sacrifice performance and simplicity. And for that EF has been a great companion. I've also used a combination of EF and DACPAC. Where I used DACPAC to manage the schema and migrations and used EF for CRUD and that's been a pretty great combo. And I definitely have to drop down to sql, especially for reporting/analysis type queries.