In this section, the StoreContext is updated for EF Core.
- [Narrator] Next up, we're going to add and update the store context. So the EF Core DbContext has changed fairly significantly since EF 6. Instead of just passing in the connection string name into the base, it's actually configured using a DbContextOptions instance. And this sets the data base provider, connection string, and a host of other options that are available. Like the rest of .NET Core, the DbContext now fully supports dependency injection, and also provides the OnConfiguring method as a fallback mechanism in case the DbContextOptions was not passed into the constructor.
There's also a few changes in the FluentAPI. Individual column settings, such as hasPrecision, have been removed for maximum flexibility. Okay, in this SpyStoreDAL project, let's open up Program.cs, go ahead and get rid of the Console.WriteLine, and then create a new directory named EF, and we want to mirror the original projects as closely as possible.
And then pull up File Explorer, and we can drag and drop the StoreContext into the newly created EF folder. Let's open up the StoreContext. We need to fix the using statements. First we're going to add in using System, using SpyStoreModels can stay. We're going to get rid of System.Data.Entity and we're actually going to replace that with Microsoft.EntityFrameworkCore.
And then we can remove the line for the initializers, because we won't be calling any from the context. So we still derive from DbContext, that hasn't changed. But we want to get rid of the call to the base, 'cause that doesn't apply anymore, and there are no true data initializers in EF Core like there were in EF 6, so we can delete that line 'cause we won't carry that forward.
For our models, just get rid of the virtual. The rest of it can stay the same. The next changes we need to make are to the OnModelCreating override. And the first change is minor, it's actually ModelBuilder and not DbModelBuilder. Also, IsFixedLength is no longer valid. So we'll go ahead and delete those.
It doesn't affect the database at all, so it's nothing negative there. And then HasPrecison has been removed in favor of the HasColumnType. I'm not sure that I'm in favor of it. HasPrecision was nice and complied time-checking, where HasColumnType just takes a string, but they didn't ask my opinion. So let's change this to HasColumnType as we see there, and it is a string, decimal(19,4), that is precision and then scale.
And then we will copy that down here to that line. So that completes the changes we need to make to OnModelCreating. Now it's time to add in the constructor for dependency injection, and then the OnConfiguring override. So let's add another constructor, StoreContext, and this is going to take DbContextOptions, and we will just pass that into the base, like that.
We don't need to do anything in that method. And then we want to add in a protected override, void OnConfiguring, and this takes a DbContextOptionsBuilder. And we'll just call it optionsBuilder. And we want to check to see if a DbContextOptions was actually passed into the constructor. And this is very simple.
If it was passed in and the DbContext is configured, then the optionsBuilder is configured property is set to true. So we want to see if it wasn't, very simply, we say optionsBuilder.IsConfigured. Make sure you put the bang in front of that to negate it. And then we are going to say optionsBuilder.UseSqlServer, and the first parameter to pass in is a connection string.
And this is the exact same, well, it's close to the same connection string that we used in the 2.2 project, let me just paste it in and show you the change. Everything is the same, except I changed the name to be a little different so that both applications can be running, and we demonstrate how to update the database using migrations with EF Core. The final thing that I'm going to set here is in Options, and the option that I'm going to set is EnableRetryOnFailure.
And what this does is configure Entity Framework to use a SQL Server retrying execution strategy, and that strategy says, if certain transient exceptions occur, go ahead and automatically retry up to a set retry count with a delay between each retry. You can set what those counts are and the delay time. Most people start with the defaults and move from there.
You can also build your own custom execution strategy, but that's certainly beyond the scope of this course. And that completes updating the context for EF Core.
- Creating the .NET Core project
- Adding Entity Framework
- Migrating the data access layer (DAL)
- Configuring services and the HTTP pipeline
- Adding remaining services to the dependency injection container
- Migrating controllers and actions
- Testing the services