Confusion over EF Auto Migrations and seeding - seeding every program start

不羁岁月 提交于 2019-11-27 17:30:49

The fact that the Seed method ran only when the database changed was quite limiting for the database initializers that shipped in EF 4.1. It was limiting because sometimes you needed to update seed data without changing the database, but to make that happen you had to artificially make it seem like the database had changed.

With Migrations the use of Seed became a bit different because it could no longer be assumed that the database was starting empty--that's kind of the point of Migrations after all. So a Seed method in Migrations has to assume that the database exists and may already have data in it, but that data might need to be updated to take into account the changes made to the database for the Migrations. Hence the use of AddOrUpdate.

So now we have a situation where Seed must be written to take account of existing data, which means that there is really no need to perpetuate the limitations of the EF 4.1 Seed method such that you would have to make it seem like the database had changed just in order to get Seed to run. Hence Seed now runs every time the context is used for the first time in the app domain. This shouldn't change the way Seed is imlemented since it needs to handle the case where the data is already present anyway.

If it causes perf issues because you have a lot of Seed data then it is usually quiet easy to add checks into the Seed method that query the database to determine how much work needs to be done before doing it.

Guillermo Ruffino

I somewhat agree with Arthur Vickers response, however IMO Seed is for DbMigrations and I don't want the Seed method to be checking everything every time, e.g. If I have 4 migrations then I would need to test somehow which data must be seeded and that will be 4 more database hits at least. In case you still would like to have the behavior of running Seed method only when migrations are applied, like me, I came with my own implementation of the IDatabaseInitializer strategy

public class CheckAndMigrateDatabaseToLatestVersion<TContext, TMigrationsConfiguration>
    : IDatabaseInitializer<TContext>
    where TContext : DbContext
    where TMigrationsConfiguration : DbMigrationsConfiguration<TContext>, new()
{
    public virtual void InitializeDatabase(TContext context)
    {
        var migratorBase = ((MigratorBase)new DbMigrator(Activator.CreateInstance<TMigrationsConfiguration>()));
        if (migratorBase.GetPendingMigrations().Any())
            migratorBase.Update();
    }
}

Another option might be to load a custom db initializer class at runtime within the seed method. The Production app could then load a dummy initializer, while the dev app could load the real initializer. You could use Unity/MEF

    // Unity Dependency Injection Prop
    [Dependency]
    property IMyInitializer initializer;

    protected override Seed(YourContextClass context)
    {
       initializer.Seed(context);
    }

Something like that. You'd then switch initializers once you have the DB set-up in Production, to the dummy one, that would do nothing.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!