Entity Framework Code First迁移后如何添加自定义后置处理步骤？

问题 #

在Entity Framework Code First迁移中，能否添加迁移后置处理方法？

当前我们的做法是将Visual Studio项目中的存储过程文件加载至单独迁移的Up方法中执行：

protected override void Up(MigrationBuilder migrationBuilder)
{
    var script = ScriptMgr.LoadStoredProc( "StoredProcThatChanged.sql" );
    migrationBuilder.Sql( script );
}

但这种方式存在弊端：每次存储过程文件变更时，需要新建迁移以确保重新执行，但旧迁移也会读取同一文件，导致旧迁移被修改，这不符合规范。如果存在可重新应用所有存储过程的迁移后置步骤就能解决该问题，请问是否可行？如何实现？

另外，我研究EF Core源码后发现可以通过继承Migrator类重写GenerateScript方法：

class MyMigrator : Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator
{
    public string GenerateScript(
            string? fromMigration = null,
            string? toMigration = null,
            MigrationsSqlGenerationOptions options = MigrationsSqlGenerationOptions.Default) 
    {
        var result = base.GenerateScript( fromMigration, toMigration, options);
        results += MyPostSteps(...);
        return results;
    }
}

请问该方案是否可行？如何替换默认Migrator？

解决方案 #

一、实现迁移后置处理的可行方案 #

完全可以通过EF Core的扩展机制实现迁移后置处理，推荐两种更简洁的方式，避免修改旧迁移的问题：

1. 利用IMigrationCommandExecutor扩展

通过自定义命令执行器，在所有迁移命令执行完成后统一执行存储过程脚本：

public class PostMigrationCommandExecutor : IMigrationCommandExecutor
{
    private readonly IMigrationCommandExecutor _innerExecutor;
    private readonly IServiceProvider _serviceProvider;

    public PostMigrationCommandExecutor(IMigrationCommandExecutor innerExecutor, IServiceProvider serviceProvider)
    {
        _innerExecutor = innerExecutor;
        _serviceProvider = serviceProvider;
    }

    public void Execute(IReadOnlyList<MigrationCommand> migrationCommands)
    {
        // 先执行原有迁移命令
        _innerExecutor.Execute(migrationCommands);
        
        // 执行后置处理：加载并执行所有存储过程脚本
        var scriptPaths = Directory.GetFiles(Path.Combine(AppContext.BaseDirectory, "StoredProcs"), "*.sql");
        using var dbContext = _serviceProvider.GetRequiredService<YourDbContext>();
        foreach (var path in scriptPaths)
        {
            var script = File.ReadAllText(path);
            dbContext.Database.ExecuteSqlRaw(script);
        }
    }

    public async Task ExecuteAsync(IReadOnlyList<MigrationCommand> migrationCommands, CancellationToken cancellationToken = default)
    {
        // 异步版本实现
        await _innerExecutor.ExecuteAsync(migrationCommands, cancellationToken);
        
        var scriptPaths = Directory.GetFiles(Path.Combine(AppContext.BaseDirectory, "StoredProcs"), "*.sql");
        using var dbContext = _serviceProvider.GetRequiredService<YourDbContext>();
        foreach (var path in scriptPaths)
        {
            var script = File.ReadAllText(path);
            await dbContext.Database.ExecuteSqlRawAsync(script, cancellationToken);
        }
    }
}

然后在DbContext的OnConfiguring方法中替换服务：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.ReplaceService<IMigrationCommandExecutor, PostMigrationCommandExecutor>();
}

这种方式的优势是：每次执行迁移时，不管是新增迁移还是回滚，都会在迁移完成后重新执行所有存储过程，无需修改旧迁移，也不用每次改存储过程都新建迁移。

2. 自定义迁移操作类

如果需要更灵活的控制，可以创建一个自定义的迁移操作，在每次迁移的Up方法末尾调用，但这种方式需要确保所有新迁移都调用该方法，适合团队约定执行：

public static class MigrationExtensions
{
    public static void ApplyAllStoredProcs(this MigrationBuilder migrationBuilder)
    {
        var scriptPaths = Directory.GetFiles(Path.Combine(AppContext.BaseDirectory, "StoredProcs"), "*.sql");
        foreach (var path in scriptPaths)
        {
            var script = File.ReadAllText(path);
            migrationBuilder.Sql(script);
        }
    }
}

然后在迁移的Up方法中调用：

protected override void Up(MigrationBuilder migrationBuilder)
{
    // 原有迁移逻辑
    migrationBuilder.CreateTable(...);
    
    // 执行后置存储过程
    migrationBuilder.ApplyAllStoredProcs();
}

这种方式的好处是：可以明确控制何时执行，但需要团队遵守调用约定。

二、重写Migrator类的方案可行性及替换方法 #

你提出的重写Migrator类的方案是可行的，但需要注意以下几点：

1. 可行性说明：Migrator类是EF Core内部的迁移执行核心，重写GenerateScript方法可以在生成迁移脚本时追加自定义逻辑，但这种方式仅影响Script-Migration命令生成的脚本，不会直接影响Update-Database命令的执行逻辑。如果你的需求是生成脚本时追加内容，这个方案适用；如果是要在实际执行迁移时触发后置逻辑，推荐用上面的IMigrationCommandExecutor方案。

2. 替换默认Migrator的步骤：

   • 首先，自定义Migrator需要完整实现构造函数，因为EF Core的内部类依赖多个服务：

     public class MyMigrator : Migrator
     {
         public MyMigrator(IMigrationsAssembly migrationsAssembly, IMigrationCommandExecutor migrationCommandExecutor, IRelationalConnection connection, IMigrationsSqlGenerator migrationsSqlGenerator, IRawSqlCommandBuilder rawSqlCommandBuilder, IMigrationHistoryRepository migrationHistoryRepository, ICurrentDbContext currentDbContext, IDbContextOptions options, ILogger<Migrator> logger) 
             : base(migrationsAssembly, migrationCommandExecutor, connection, migrationsSqlGenerator, rawSqlCommandBuilder, migrationHistoryRepository, currentDbContext, options, logger)
         {
         }
     
         public override string GenerateScript(string? fromMigration = null, string? toMigration = null, MigrationsSqlGenerationOptions options = MigrationsSqlGenerationOptions.Default)
         {
             var baseScript = base.GenerateScript(fromMigration, toMigration, options);
             // 追加自定义存储过程脚本
             var procScript = File.ReadAllText(Path.Combine(AppContext.BaseDirectory, "StoredProcs", "AllProcs.sql"));
             return baseScript + "\n" + procScript;
         }
     }
     

   • 然后在DbContext的OnConfiguring方法中替换服务：

     protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
     {
         optionsBuilder.ReplaceService<IMigrator, MyMigrator>();
     }
     

   注意：IMigrator是EF Core的公开接口，替换时需要使用这个接口而不是具体的内部Migrator类，确保兼容性。

内容的提问来源于stack exchange，提问作者Sam Carleton