3 ms·
Many people are choosing it because it's the blessed way of doing things, but it is crazy overkill and such a heavy hammer for many cases. There is rarely a ca
by pknopf 8y ago
Many people are choosing it because it's the blessed way of doing things, but it is crazy overkill and such a heavy hammer for many cases.
There is rarely a case to use EF.
- Solar19 8y agoWhat is EF?
- wantoncl 8y agoEntity Framework
- sdfin 8y agoDoes what you say also apply to EF Core? I don't know the previous EF version, but EF Core seemed simple to me. Particularly after comparing it with what I knew about Hibernate.
- pknopf 8y agoI have the same opinion on both. My default is to just use ADO.NET with Dapper or ServiceStack.OrmLite.
- JamesBarney 8y agoMind explaining this more? I love EF and how quickly you can get spin up a database and get started writing LINQ queries against it. Also how easy it is to get code reuse which is a pain in the butt with sql, or throw together a multi tenant app with global query filters.
- pknopf 8y agoYou 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.