如何在EF Core 8中分离种子数据与迁移代码以缩减.Designer文件体积

针对你遇到的迁移.Designer.cs文件因大量种子数据膨胀、编译耗时增加的问题，以下是几种可行的优化方案：

1. 将种子数据与迁移逻辑彻底分离（优先推荐） #

不要把种子数据放在OnModelCreating或其分部方法中，而是单独实现数据初始化逻辑，在应用启动时执行，而非依赖迁移生成插入语句。

示例实现： #

// 单独的种子数据初始化类
public static class DbSeeder
{
    public static async Task SeedAsync(MyDbContext context)
    {
        // 先判断数据是否已存在，避免重复插入
        if (!await context.Locations.AnyAsync())
        {
            var seedLocations = GetSeedLocations();
            await context.Locations.AddRangeAsync(seedLocations);
            await context.SaveChangesAsync();
        }
    }

    // 封装种子数据列表
    private static List<Location> GetSeedLocations()
    {
        return new List<Location>
        {
            new Location { Id = 1, Name = "总部" },
            new Location { Id = 2, Name = "华东分部" },
            // ... 你的500条数据
        };
    }
}

启动时调用初始化逻辑： #

var app = builder.Build();

// 在应用启动阶段执行种子数据初始化
using (var scope = app.Services.CreateScope())
{
    var dbContext = scope.ServiceProvider.GetRequiredService<MyDbContext>();
    await DbSeeder.SeedAsync(dbContext);
}

app.Run();

优势：迁移文件不再包含任何种子数据，.Designer.cs体积会大幅缩小；种子数据逻辑独立，修改和维护更灵活；避免了每次迁移都重复生成大量插入语句。

2. 手动编写种子数据SQL脚本，脱离迁移生成 #

如果必须通过数据库初始化流程执行种子数据，可以跳过EF自动生成种子语句的逻辑，改用手动维护SQL脚本：

1. 临时注释掉OnModelCreating中的HasData代码，运行ef migrations add YourMigrationName生成干净的迁移文件；
2. 恢复HasData代码（仅用于本地开发时的模型验证），同时编写对应的批量插入SQL脚本（如Seed_Locations.sql）；
3. 执行ef database update完成结构迁移后，手动运行SQL脚本插入种子数据，或在应用启动时通过EF执行脚本。

优势：迁移文件保持轻量化，种子数据的SQL脚本可单独版本控制，批量插入的效率也比EF生成的单条语句更高。

3. 自定义迁移SQL生成器（进阶方案） #

通过EF Core的扩展点，自定义IMigrationsSqlGenerator实现，重写种子数据的SQL生成逻辑，将多条数据合并为批量插入语句，而非每条数据生成单独的INSERT：

public class CustomMigrationsSqlGenerator : SqlServerMigrationsSqlGenerator
{
    public CustomMigrationsSqlGenerator(
        MigrationsSqlGeneratorDependencies dependencies,
        IRelationalAnnotationProvider annotations)
        : base(dependencies, annotations)
    {
    }

    protected override void GenerateInsertData(InsertDataOperation operation)
    {
        // 重写生成逻辑，将多条数据合并为单个INSERT语句
        // 示例仅针对SQL Server，需根据你的数据库类型调整
        var tableName = Dependencies.SqlGenerationHelper.DelimitIdentifier(operation.Table, operation.Schema);
        var columnNames = operation.Columns.Select(c => Dependencies.SqlGenerationHelper.DelimitIdentifier(c));
        var valuesClauses = operation.Values.Select(v => $"({string.Join(", ", v.Select(FormatValue))})");

        var sql = $"INSERT INTO {tableName} ({string.Join(", ", columnNames)}) VALUES {string.Join(", ", valuesClauses)};";
        Statement(sql);
    }

    private string FormatValue(object value)
    {
        return value switch
        {
            string s => $"'{s.Replace("'", "''")}'",
            null => "NULL",
            _ => value.ToString()
        };
    }
}

然后在DbContext中注册自定义生成器：

protected override void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IMigrationsSqlGenerator, CustomMigrationsSqlGenerator>();
}

优势：既保留了种子数据随迁移执行的特性，又大幅减少了.Designer.cs中的代码量（批量语句替代大量单条插入）。

4. 优化现有迁移合并策略 #

如果无法脱离迁移中的种子数据，可以优化合并迁移的频率和方式：

• 每次合并时，将旧迁移文件归档到单独目录，仅保留最新的基础迁移和最近3-5个增量迁移；
• 合并时重新生成包含当前所有模型和种子数据的基础迁移，彻底替换旧的迁移链。

优势：减少需要编译的迁移文件数量，直接降低编译耗时。

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