在开发涉及到数据库的程序时，常会遇到一开始设计的结构不能满足需求需要再添加新字段或新表的情况，这时就需要进行数据库迁移。
实现数据库迁移有很多种办法，从手动管理各个版本的ddl脚本，到实现自己的migrator，或是使用Entity Framework提供的Code First迁移功能。
Entity Framework提供的迁移功能可以满足大部分人的需求，但仍会存在难以分项目管理迁移代码和容易出现"context has changed"错误的问题。
这里我将介绍ZKWeb网页框架在Fluent NHibernate和Entity Framework Core上使用的办法。
可以做到添加实体字段后，只需刷新网页就可以把变更应用到数据库。
实现全自动迁移的思路
数据库迁移需要指定变更的部分，例如添加表和添加字段。
而实现全自动迁移需要自动生成这个变更的部分，具体来说需要
- 获取数据库现有的结构
- 获取代码中现有的结构
- 对比结构之间的差异并生成迁移
这正是Entity Framework的Add-Migration(或dotnet ef migrations add)命令所做的事情，
接下来我们将看如何不使用这类的命令，在NHibernate, Entity Framework和Entity Framework Core中实现全自动的处理。
Fluent NHibernate的全自动迁移
ZKWeb框架使用的完整代码可以查看这里
首先Fluent NHibernate需要添加所有实体的映射类型，以下是生成配置和添加实体映射类型的例子。
配置类的结构可以查看这里
var db = MsSqlConfiguration.MsSql2008.ConnectionString("连接字符串");
var configuration = Fluently.Configure();
configuration.Database(db);
configuration.Mappings(m => {
m.FluentMappings.Add(typeof(FooEntityMap));
m.FluentMappings.Add(typeof(BarEntityMap));
...
});
接下来是把所有实体的结构添加或更新到数据库。
NHibernate提供了SchemaUpdate，这个类可以自动检测数据库中是否已经有表或字段，没有时自动添加。
使用办法非常简单，以下是使用的例子
configuration.ExposeConfiguration(c => {
// 第一个参数 false: 不把语句输出到控制台
// 第二个参数 true: 实际在数据库中执行语句
new SchemaUpdate(c).Execute(false, true);
});
到这一步就已经实现了全自动迁移，但我们还有改进的余地。
因为SchemaUpdate不保存状态，每次都要检测数据库中的整个结构，所以执行起来EF的迁移要缓慢很多，
ZKWeb框架为了减少每次启动网站的时间，在执行更新之前还会检测是否需要更新。
var scriptBuilder = new StringBuilder();
scriptBuilder.AppendLine("/* this file is for database migration checking, don't execute it */");
new SchemaExport(c).Create(s => scriptBuilder.AppendLine(s), false);
var script = scriptBuilder.ToString();
if (!File.Exists(ddlPath) || script != File.ReadAllText(ddlPath)) {
new SchemaUpdate(c).Execute(false, true);
onBuildFactorySuccess = () => File.WriteAllText(ddlPath, script);
}
这段代码使用了SchemaExport来生成所有表的DDL脚本，生成后和上次的生成结果对比，不一致时才调用SchemaUpdate更新。
NHibernate提供的自动迁移有以下的特征，使用时应该注意
- 字段只会添加，不会删除，如果你重命名了字段原来的字段也会保留在数据库中
- 字段类型如果改变，数据库不会跟着改变
- 关联的外键如果改变，迁移时有可能会出错
总结NHibernate的自动迁移只会添加表和字段，基本不会修改原有的结构，有一定的限制但是比较安全。
Entity Framework的全自动迁移
ZKWeb框架没有支持Entity Framework 6，但实现比较简单我就直接上代码了。
例子
// 调用静态函数，放到程序启动时即可
// Database是System.Data.Entity.Database
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, MyConfiguration>());
public class MyConfiguration : DbMigrationsConfiguration<MyContext> {
public MyConfiguration() {
AutomaticMigrationsEnabled = true; // 启用自动迁移功能
AutomaticMigrationDataLossAllowed = true; // 允许自动删字段，危险但是不加这个不能重命名字段
}
}
Entity Framework提供的自动迁移有以下的特征，使用时应该注意
- 如果字段重命名，旧的字段会被删除掉，推荐做好数据的备份和尽量避免重命名字段
- 外键关联和字段类型都会自动变化，变化时有可能会导致原有的数据丢失
- 自动迁移的记录和使用工具迁移一样，都会保存在
__MigrationHistory表中，切勿混用否则代码将不能用到新的数据库中
总结Entity Framework的迁移可以保证实体和数据库之间很强的一致性，但是使用不当会导致原有数据的丢失，请务必做好数据库的定时备份。
Entity Framework Core的全自动迁移
Entity Framework Core去掉了SetInitializer选项，取而代之的是DatabaseFacade.Migrate和DatabaseFacade.EnsureCreated。
DatabaseFacade.Migrate可以应用使用ef命令生成的迁移代码，避免在生产环境中执行ef命令。
DatabaseFacade.EnsureCreated则从头创建所有数据表和字段，但只能创建不能更新，不会添加纪录到__MigrationHistory。
这两个函数都不能实现全自动迁移，ZKWeb框架使用了EF内部提供的函数，完整代码可以查看这里
Entity Framework Core的自动迁移实现比较复杂，我们需要分两步走。
- 第一步 创建迁移记录
__ZKWeb_MigrationHistory表，这个表和EF自带的结构相同，但这个表是给自己用的不是给ef命令用的 - 第二部 查找最后一条迁移记录，和当前的结构进行对比，找出差异并更新数据库
第一步的代码使用了EnsureCreated创建数据库和迁移记录表，其中EFCoreDatabaseContextBase只有迁移记录一个表。
创建完以后还要把带迁移记录的结构保留下来，用作后面的对比，如果这里不保留会导致迁移记录的重复创建错误。
using (var context = new EFCoreDatabaseContextBase(Database, ConnectionString)) {
// We may need create a new database and migration history table
// It's done here
context.Database.EnsureCreated();
initialModel = context.Model;
}
在执行第二步之前，还需要先判断连接的数据库是不是关系数据库，
因为Entity Framework Core以后还会支持redis mongodb等非关系型数据库，自动迁移只应该用在关系数据库中。
using (var context = new EFCoreDatabaseContext(Database, ConnectionString)) {
var serviceProvider = ((IInfrastructure<IServiceProvider>)context).Instance;
var databaseCreator = serviceProvider.GetService<IDatabaseCreator>();
if (databaseCreator is IRelationalDatabaseCreator) {
// It's a relational database, create and apply the migration
MigrateRelationalDatabase(context, initialModel);
} else {
// It maybe an in-memory database or no-sql database, do nothing
}
}
第二步需要查找最后一条迁移记录，和当前的结构进行对比，找出差异并更新数据库。
先看迁移记录表的内容，迁移记录表中有三个字段
- Revision 每次迁移都会+1
- Model 当前的结构，格式是c#代码
- ProductVersion 迁移时Entity Framework Core的版本号
Model存放的代码例子如下，这段代码记录了所有表的所有字段的定义，是自动生成的。
后面我将会讲解如何生成这段代码。
using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Infrastructure;
using Microsoft.EntityFrameworkCore.Metadata;
using Microsoft.EntityFrameworkCore.Migrations;
using ZKWeb.ORM.EFCore;
namespace ZKWeb.ORM.EFCore.Migrations
{
[DbContext(typeof(EFCoreDatabaseContext))]
partial class Migration_636089159513819123 : ModelSnapshot
{
protected override void BuildModel(ModelBuilder modelBuilder)
{
modelBuilder
.HasAnnotation("ProductVersion", "1.0.0-rtm-21431")
.HasAnnotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn);
modelBuilder.Entity("Example.Entities.Foo", b =>
{
b.Property<Guid>("Id")
.ValueGeneratedOnAdd();
b.Property<string>("Name")
.IsRequired();
});
}
}
}
}
接下来查找最后一条迁移记录:
var lastModel = initialModel;
var histories = context.Set<EFCoreMigrationHistory>();
var lastMigration = histories.OrderByDescending(h => h.Revision).FirstOrDefault();
存在时，编译Model中的代码并且获取ModelSnapshot.Model的值，这个值就是上一次迁移时的完整结构。
不存在时，将使用initialModel的结构。
编译使用的是另外一个组件，你也可以用Roslyn CSharp Scripting包提供的接口编译。
if (lastMigration != null) {
// Remove old snapshot code and assembly
var tempPath = Path.GetTempPath();
foreach (var file in Directory.EnumerateFiles(
tempPath, ModelSnapshotFilePrefix + "*").ToList()) {
try { File.Delete(file); } catch { }
}
// Write snapshot code to temp directory and compile it to assembly
var assemblyName = ModelSnapshotFilePrefix + DateTime.UtcNow.Ticks;
var codePath = Path.Combine(tempPath, assemblyName + ".cs");
var assemblyPath = Path.Combine(tempPath, assemblyName + ".dll");
var compileService = Application.Ioc.Resolve<ICompilerService>();
var assemblyLoader = Application.Ioc.Resolve<IAssemblyLoader>();
File.WriteAllText(codePath, lastMigration.Model);
compileService.Compile(new[] { codePath }, assemblyName, assemblyPath);
// Load assembly and create the snapshot instance
var assembly = assemblyLoader.LoadFile(assemblyPath);
var snapshot = (ModelSnapshot)Activator.CreateInstance(
assembly.GetTypes().First(t =>
typeof(ModelSnapshot).GetTypeInfo().IsAssignableFrom(t)));
lastModel = snapshot.Model;
}
和当前的结构进行对比:
// Compare with the newest model
var modelDiffer = serviceProvider.GetService<IMigrationsModelDiffer>();
var sqlGenerator = serviceProvider.GetService<IMigrationsSqlGenerator>();
var commandExecutor = serviceProvider.GetService<IMigrationCommandExecutor>();
var operations = modelDiffer.GetDifferences(lastModel, context.Model);
if (operations.Count <= 0) {
// There no difference
return;
}
如果有差异，生成迁移命令(commands)和当前完整结构的快照(modelSnapshot)。
上面Model中的代码由这里的CSharpMigrationsGenerator生成，modelSnapshot的类型是string。
// There some difference, we need perform the migration
var commands = sqlGenerator.Generate(operations, context.Model);
var connection = serviceProvider.GetService<IRelationalConnection>();
// Take a snapshot to the newest model
var codeHelper = new CSharpHelper();
var generator = new CSharpMigrationsGenerator(
codeHelper,
new CSharpMigrationOperationGenerator(codeHelper),
new CSharpSnapshotGenerator(codeHelper));
var modelSnapshot = generator.GenerateSnapshot(
ModelSnapshotNamespace, context.GetType(),
ModelSnapshotClassPrefix + DateTime.UtcNow.Ticks, context.Model);
插入迁移记录并执行迁移命令:
// Insert the history first, if migration failed, delete it
var history = new EFCoreMigrationHistory(modelSnapshot);
histories.Add(history);
context.SaveChanges();
try {
// Execute migration commands
commandExecutor.ExecuteNonQuery(commands, connection);
} catch {
histories.Remove(history);
context.SaveChanges();
throw;
}
到这里就完成了Entity Framework Core的自动迁移，以后每次有更新都会对比最后一次迁移时的结构并执行更新。
Entity Framework Core的迁移特点和Entity Framework一样，可以保证很强的一致性但需要注意防止数据的丢失。
写在最后
全自动迁移数据库如果正确使用，可以增强项目中各个模块的独立性，减少开发和部署的工作量。
但是因为不能手动控制迁移内容，有一定的局限和危险，需要了解好使用的ORM迁移的特点。
写在最后的广告
ZKWeb网页框架已经在实际项目中使用了这项技术，目前来看迁移部分还是比较稳定的。
这项技术最初是为了插件商城而开发的，在下载安装插件以后不需要重新编译主程序，不需要执行任何迁移命令就能使用。
目前虽然没有实现插件商城，也减少了很多日常开发的工作。
如果你有兴趣，欢迎加入ZKWeb交流群522083886共同探讨。
