A combination of the best parts of everything

—Lander, 2019

(references from https://devblogs.microsoft.com/dotnet/introducing-net-5/)

EF6, EFCore, and .NET 5

With the direction of .NET 5 being the wave of the future, we need to know what that will do to our current EF6 and EFCore applications. The really good news for us is that we should be able to keep working with our solutions.

.Net Core 3.0+ gave us the ability to use an EF6 implementation. The .Net Framework also runs EF6. .NET 5 is bringing all of this together, so both EFCore and EF6 should work as expected in .NET 5.

Core is going away, right?

Even more confusion with this vNext name for EF might be caused since the Core moniker is slated to go away with the .NET 5 release in November.

All of this to really just say that we might see a name change of this product, or we might not. Either way, what we can rely on is that the vNext EF – EFCore5 - is out and ready to be used and will work in the .NET 5 release that happens at the end of 2020. The good news is that it also works on the latest release of EFCore. That means that even if you don’t upgrade your current production apps out of the .Net Core 3.1 release, you will likely still be able to use EFCore5.

Many-to-many navigation properties

https://github.com/dotnet/efcore/issues/19003

To be honest, I can see why this was so heavily requested to be added to the new version. In a nutshell, when working with many-to-many relationships in the past, we would create the navigation properties, and then to load the data we need to use along with appropriate includes to bring the data into our query results.

Not having to directly include the join in the query will make it quite a bit more concise and will seem more readable.

Table-per-type (TPT) inheritance mapping

Table per type is a pattern that, when implemented, works exactly how it sounds. With TPT , as you build out an object hierarchy with inheritance, each new type gets its own table. Contrast this with TPH – table per hierarchy – where the entire set of objects are stored in one table.

So here is the interesting thing. TPT is already able to be implemented in EFCore 3.1. However, there are a few hoops to jump through and you end up with one table (much like TPH) that has all types in it with a simple differentiator field. As you might imagine, this can quickly become non-performant in a high-volume database. First you have to select by differentiator, and then filter the results further to get the subset of the specific type that you need for your operation. Sure, you can put indexes on things, but it still means your table grows exponentially as more types are added.

With EFCore5, we’ll get true TPT capabilities. Unfortunately, as per the documentation on the plan, this may come with some breaking changes that would require rework from an existing solution moving into EFCore5.

Filtered include

Another feature that will surely help our day-to-day operations is the ability to filter an include statement. As of now, if you try to add a filter on an include, you get an exception and the query won’t execute.

The filtered include will provide the ability to select only the subset of joined table rows that match based on the filter.

Rationalize ToTable, ToQuery, ToView, FromSql

In the operation of EF, there are different things that can happen, whether a query is executed, a migration generates a table definition change, and views exist with or without keys. All of this working together has led to a place where you really need to know the specific way it works for each operation.

It seems that the EFCore5 release will be working to try to make these operations standard for each To or From call so that the developer won’t have to know some of the internal nuances of the build or update pipeline to get the results they need.

For example, a situation might exist where specific operations like Create, Update, and Read need to happen against a physical table, but perhaps the Read comes from a procedure result or a view. In those cases, the goal would be to correctly get objects created in the migration so that the system will work as planned.

Another goal of this work is to get the mappings to other objects working in a new way that should be easier for developers, for example, trying to get the mapping to stored procedures for your Create, Update, and Delete operations, or allowing the ability to execute raw SQL for defining objects from a query.

Migrations and deployment experience

For code-first developers, this area has consistently been one where the experience is not always ideal. If you’ve worked in EF6, you know that even the date of the migration is important. Each migration needs to run in order according to the date on the migration. This leads to a lot of migration conflicts where one developer beats another developer to production, and the second developer must set their database correctly by rolling back their migration, delete their migration, get the new code, update the database, and then finish by re-creating their original migration with the new timestamp and model snapshot.

This problem is especially painful when a migration conflict happens on the production database. As such, both development and deployment have been troubled by migration conflicts. This experience is vastly improved in EFCore and will continue to be improved in EFCore5.

With EFCore5, one goal will be to create a better team experience, presumably by mitigating even more of these migration conflicts and even being smart enough to handle situations that would cause a conflict.

Another major change will be that the ability to run migrations across all platforms should exist. As a result of being able to run migrations on any platform in EFCore5, the overall experience should be especially improved for Linux and Mac users.

EFCore platforms experience

As mentioned at the start of the chapter, an overarching goal of .NET 5 will be the ability to have a similar experience on all types of projects, from Xamarin to Blazor to ASP.Net web applications.

As such, another goal of the EFCore5 release will be an improved experience working with EF for all of the major platforms, not just ASP.Net.

Performance

As EF has iterated through the years, each version has added performance improvements. EFCore definitely has improved performance over EF6 on just about every metric.

I would expect that EFCore5 will continue to improve on the performance of all operations. Additionally, the documentation points out that there is a plan for a new batching API to allow multiple statements to be batched for increased performance.