This post was written by Alina Popa, a software engineer on the .NET team.
Entity Framework Core (EF Core) is a lightweight and extensible version of the Entity Framework (EF) data access technology which is cross-platform and supports multiple database providers. You can find a comparison of EF Core vs. EF6 under the Entity Framework documentation.
When moving an application from EF6 to EF Core, you may encounter features that existed in EF6 but either are not present or are not yet implemented in EF Core. For many of those features, however, you can implement equivalent functionality.
With EF6 you can seed a database with initial data by overriding one of the following Seed()methods:
EF Core does not provide similar APIs, and database initializers also no longer exist in EF Core. To seed the database, you would put the database initialization code in the application startup. If you are using migrations, call context.Database.Migrate(), otherwise use context.Database.EnsureCreated()/EnsureDeleted().
The patterns for seeding the database are discussed in issue 3070in the Entity Framework Core repository on GitHub. The recommended approach is to run the seeding code within a service scope in Startup.Configure():
You can find herean example of database initialization that uses migrations. The MusicStoresample also uses this pattern for seeding.
In Entity Framework 6 we can create custom configurations of properties and tables by using model-based conventions. For example, the following code in EF6 creates a convention to throw an exception when the column name is longer than 30 characters:
EF Core does not provide the IStoreModelConventioninterface; however, we can create this convention by accessing internal services (extending lower level components in EF Core). In the following example we implement a model validator which checks for very long table and column names:
Registering and using the ModelValidator created here is explained later in this article.
Entity Framework 6 provides the ability to intercept a context using IDbCommandInterceptor. Interceptors let you to get into the pipeline just before and just after a query or command is sent to the database. Entity Framework Core doesn’t have any interceptors yet. The functionality can be achieved by accessing internal services, in a similar way as the example described above for the model validator. The following example implements IEntityStateListenerto modify an entity just before it is added to the database:
To use the StateListener and the ModelValidator in your context, create a ServiceProvider and use it in OptionsBuilder:
The APIs for accessing internal services may change in the future releases, and there is a risk that the application will break when updated to a new version of Entity Framework Core. The approaches described above should not be considered as long-term solutions, but as workarounds until we have a first class way of achieving the functionality.
Interceptors and seeding are high on the feature backlog and the Entity Framework team plans to address them in the near future.