In late October, I spoke at DevIntersection. One of my sessions was called EF6 or EF Core? How Do I Choose? As I’ve been an authority on EF since it’s earliest days, people have been asking me this question frequently, which inspired the talk.
The session was not recorded but I’m sharing my slides on SlideShare. I go into detail on the topic in my upcoming Pluralsight course, “EF Core: Getting Started” which I am currently building. Watch my Pluralsight author page (as well as twitter.com/julielerman and this blog!) for its release.
In the meantime, here is a link to the slides from the DevIntersection talk.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
5 thoughts on “EF6 or EF Core? How Do I Choose?”
Is it necessary to *choose* between EF6 and EF Core? Or can we use *both* in a .NET Core application? For example can I used EF Core to access a Microsoft SQL Server and EF6 to access a DB2 database? (since apparently DB2 isn’t yet really supported on EF Core)
Great question. What I would suggest is separation of concerns to solve this problem. Create an API for the EF6 stuff and another for the EF Core work. Then interact with them as needed. Design the ef6 based API as closely as you can to how EF Core works. Then when the DB2 support comes on board for EFCore, you can migrate the ef6 api to ef core. And keep it as its own API ..separation of concerns FTW. Does that sound like a reasonable approach? I would do a proof of concept before committing too much.
We’re actively undergoing a migration from EF6 => Core as an experiment in porting one of our WebAPI services to .NET Core and it’s actually been going better than I expected. One of the biggest changes we’ve had to make is switching from depending on Lazy Loading to using Eager Loading, which has actually made us much more aware of the queries we’re depending on.
The other effortful (huehue) change we’re making definitely depends on your testing strategy, but changing from using Effort as an in-memory dbcontext to the EF Core InMemory provider is a bit different.