eShopOnWeb数据迁移方案：EF Core Migrations版本控制-优快云博客

eShopOnWeb数据迁移方案：EF Core Migrations版本控制

【免费下载链接】eShopOnWeb 项目地址: https://gitcode.com/gh_mirrors/esh/eShopOnWeb

数据迁移痛点与解决方案

在电子商务系统开发中，数据库结构的频繁变更常导致数据不一致、部署失败等问题。eShopOnWeb项目采用Entity Framework Core Migrations（EF Core 迁移）实现数据库版本控制，通过自动生成的迁移文件追踪架构变更，确保开发环境与生产环境的数据结构同步。本文将详解该项目的迁移策略、实战案例及最佳实践。

迁移文件结构与版本控制

eShopOnWeb的迁移文件集中存储于src/Infrastructure/Data/Migrations/目录，每个文件对应一次架构变更，文件名包含时间戳和描述性名称，例如：

20201202111507_InitialModel.cs：初始数据库架构
20211026175614_FixBuyerId.cs：修复BuyerId字段长度
20211231093753_FixShipToAddress.cs：完善配送地址字段约束

迁移文件核心结构

每个迁移文件包含Up()和Down()方法：

Up()：应用变更（如创建表、修改字段）
Down()：回滚变更（用于版本降级）

以初始迁移为例，其Up()方法创建了完整的数据库架构，包括Baskets、CatalogBrands、Orders等核心表：

// 简化自[20201202111507_InitialModel.cs](https://link.gitcode.com/i/cfd92de84ccd2e57f411b4ea28ac9ab1)
protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.CreateSequence("catalog_brand_hilo", incrementBy: 10);
    migrationBuilder.CreateTable(
        name: "Baskets",
        columns: table => new
        {
            Id = table.Column<int>(type: "int", nullable: false)
                .Annotation("SqlServer:Identity", "1, 1"),
            BuyerId = table.Column<string>(type: "nvarchar(40)", maxLength: 40, nullable: false)
        },
        constraints: table => table.PrimaryKey("PK_Baskets", x => x.Id)
    );
    // 其他表创建代码...
}

典型迁移场景实战

1. 初始架构设计（InitialModel）

20201202111507_InitialModel.cs定义了项目基础表结构，包括：

商品目录：Catalog（商品）、CatalogBrands（品牌）、CatalogTypes（类别）
订单系统：Orders（订单）、OrderItems（订单项）
购物车：Baskets（购物车）、BasketItems（购物车项）

关键设计特点：

使用CreateSequence创建Hi-Lo序列生成主键
采用表拆分（Table Splitting）存储复杂类型（如订单地址）
定义外键关系（如OrderItems关联Orders）

2. 字段长度调整（FixBuyerId）

随着用户量增长，原BuyerId字段长度（40字符）无法满足需求。20211026175614_FixBuyerId.cs通过AlterColumn扩展字段长度：

// 来自[20211026175614_FixBuyerId.cs](https://link.gitcode.com/i/2c00e908552a4e82bacb33c2f1786bdd)
migrationBuilder.AlterColumn<string>(
    name: "BuyerId",
    table: "Orders",
    type: "nvarchar(256)",  // 扩展为256字符
    maxLength: 256,
    nullable: false,
    defaultValue: "",
    oldClrType: typeof(string),
    oldType: "nvarchar(max)",
    oldNullable: true);

3. 非空约束强化（FixShipToAddress）

为确保订单地址完整性，20211231093753_FixShipToAddress.cs将地址字段设为非空：

// 来自[20211231093753_FixShipToAddress.cs](https://link.gitcode.com/i/adbb2c2ae6aeb03afc5eca1bc57f3010)
migrationBuilder.AlterColumn<string>(
    name: "ShipToAddress_Street",
    table: "Orders",
    type: "nvarchar(180)",
    maxLength: 180,
    nullable: false,  // 设为非空
    defaultValue: "",
    oldClrType: typeof(string),
    oldType: "nvarchar(180)",
    oldMaxLength: 180,
    oldNullable: true);

迁移工作流与最佳实践

标准迁移流程

创建迁移：

dotnet ef migrations add [MigrationName] --project src/Infrastructure/Infrastructure.csproj --startup-project src/PublicApi/PublicApi.csproj

应用迁移：

dotnet ef database update --project src/Infrastructure/Infrastructure.csproj --startup-project src/PublicApi/PublicApi.csproj

回滚迁移：

dotnet ef database update [PreviousMigrationName]

版本控制策略

命名规范：{时间戳}_{描述性名称}（如20211026175614_FixBuyerId）
分支管理：迁移文件需随代码同步提交，避免跨分支冲突
环境隔离：通过appsettings.json配置不同环境数据库连接串

常见问题处理

问题场景	解决方案	相关文件
迁移冲突	使用`dotnet ef migrations merge`合并迁移	官方文档
数据丢失风险	先备份数据，使用`Sql()`方法编写自定义迁移脚本	InitialModel.cs
生产环境迁移	使用`Script-Migration`生成SQL脚本，人工审核后执行	Infrastructure.csproj

总结与扩展

eShopOnWeb通过EF Core Migrations实现了数据库架构的可控演进，核心优势包括：

自动化追踪：无需手动编写SQL，框架自动生成变更脚本
双向迁移：支持Up()/Down()双向操作，便于版本回滚
团队协作：结构化迁移文件适合多人协作开发

扩展建议：

结合CatalogContextSeed.cs实现迁移后数据初始化
使用IDesignTimeDbContextFactory优化设计时上下文配置
集成CI/CD管道，实现迁移的自动化测试与部署

通过本文介绍的迁移方案，开发团队可安全、高效地管理数据库变更，为电子商务系统的持续迭代提供可靠保障。

【免费下载链接】eShopOnWeb 项目地址: https://gitcode.com/gh_mirrors/esh/eShopOnWeb

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考