From the course: Using Entity Framework Core with Legacy Databases

When Entity Framework Core might not be a good choice

From the course: Using Entity Framework Core with Legacy Databases

Start my 1-month free trial

When Entity Framework Core might not be a good choice

“

- [Instructor] Let's talk about some reasons you wouldn't choose Entity Framework Core. Entity Framework Core is a rewrite of Entity Framework 6, and it doesn't have all of the same features. Check the current Entity Framework documentation to see if the feature you're looking for is available in Entity Framework Core. I've opened up Microsoft's documentation website to this comparison between EF Core and EF6 features. Here you can see a feature-by-feature comparison of EF6 and EF Core. Let's highlight a few of these items. EF Core doesn't include spatial data types, like geography and geometry. It also only maps objects as table per hierarchy, whereas EF6 can also map table per type and table per concrete class. These are not common use cases, but they might be a reason to use EF6 instead of EF Core. Model-first development is also not available in Entity Framework Core. If you're used to using model-first development and you'd like to do that, Entity Framework Core is not for you. As of EF Core version 2.1, a couple big features were added to EF Core, taking them off the list of reasons not to use it. GroupBy queries at the database are supported now. It provides a lot more flexibility and speed when grouping data. Lazy loading is also now supported, but I still don't recommend it because it hides data operations behind lines of code that don't look like they've hit the database. One of the biggest reasons not to use Entity Framework Core is that your application needs the fastest possible data access. Some applications do a lot of heavy data operations with very high-performance demands, but usually business applications don't have that high of a performance demand. Entity Framework Core is still good for millions and millions of rows. Usually, the cost savings found in faster application development is more significant than just buying a more power server to run the application. The final reason not to use Entity Framework Core is that you're trying to cheat by not requiring your developers to understand what it means to work with a database. It's possible to write really bad queries in Entity Framework Core that are going to do things like bring 300,000 rows into memory and then just throw it all away immediately. There are also operations that can cause an application to use all the memory on a server and take several minutes to run, when a slightly different query could run in less than a second, and require no additional resources. Developers still have to understand what they're doing and how the code they're writing affects the database. With these considerations in mind, you can decide whether Entity Framework Core is a good fit for your project.

Contents