EF Core独立迁移项目

在官方指导中，没有特意指出针对于Migration应该如何去进行组织和管理。默认都是和Api项目或者是DbContext所在类库耦合起来了，目前看来，这种方式带来了一些问题：

1. 迁移文件和业务代码放在一起，存在被无意改动或者业务代码冲突导致迁移被覆盖的问题。
2. 迁移命令绑定了Api启动项目和类库项目，需要数据库连接字符串的支持（这个其实不算啥问题）。
3. 随着项目迭代，业务代码中的迁移文件会逐步增多，难以管理。

遵循一次只干一件事的原则，可以考虑将Migrations移出业务层，并且不与Api项目进行耦合。

独立Migrations层

项目中新建Blog.Migrations层，然后：

1. 添加DbContext所在项目的引用
2. 添加Microsoft.EntityFrameworkCore.Design引用（dotnet ef需要）
3. 添加Microsoft.EntityFrameworkCore.Tools引用（Nuget Package Manager Consolse需要）

2，3看实际情况添加。

实现设计类

独立Migrations层后， 最好是为其添加一个单独的设计类供实例化DbContext使用（因为不打算依赖Api启动项目，就需要自己实例化）

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Design;
using System.Reflection;

namespace Blog.Migrations;

public class DbContextFactory : IDesignTimeDbContextFactory<BlogDbContext>
{
    public BlogDbContextCreateDbContext(string[] args)
    {
        var optionsBuilder = new DbContextOptionsBuilder<BlogDbContext>();
        var serverVersion = new MySqlServerVersion(new Version(8, 0, 25));
        optionsBuilder.UseMySql(
            args[0],
            serverVersion,
            b => b.MigrationsAssembly(Assembly.GetExecutingAssembly().GetName().Name)
        );

        return new BlogDbContext(optionsBuilder.Options);
    }
}

这里的连接字符串用了参数传进来，所以这里有一点要注意的就是命令会需要传参数。如果觉得麻烦，也可以直接写（但不建议）。

命令行参考：

Nuget

Add-Migration 迁移名称 -Args "连接字符串"

dotnet tools

dotnet ef migrations add 迁移名称 -- "连接字符串"

结尾

独立迁移项目到这个地步就可以了，如果直接照搬会可能出现迁移无数据的情况。下一篇会记录一下通过DbContext自动注册实体的方法，精简DbContext