先说下背景，项目以前一直使用EntityFramework中的自动迁移功能，虽然一开始就知道存在一些不妥的地方，但由于时间原因一直没有更改这个方式，而这一次由于协同开发的人越来越多不得不进行改造。

为什么不再使用EntityFramework的自动迁移功能

1.迁移过程不可控

EntityFramework自动迁移所生成的脚本我们不可见，并不知道执行了什么内容，这对正式运行的项目是一个很危险的因素。

2.可能存在表丢失的情况

因为项目是模块化的，所以当一些模块在特定的情况下（我们当然希望是100%，但程序大家都懂，谁都不能保证100%）无法被加载，那么这时候EntityFramework会自作主张的删掉你的表，这在正式环境中是一个很恐怖的事情。

3.EntityFramework自动迁移不能很好的支持多租户

这点不过多说明，做过类似功能的都懂其中的辛酸。

4.性能损耗

这一点来说对我们其实没有太大不使用EF迁移的占比，但它还是存在的，因为一开始要对比__MigrationHistory表中的数据，而Model列的数据是相当庞大的。

替代的方案

因为之前在做框架的时候就考虑到了数据迁移的这个问题，顾之前还是看了一些迁移的方案的，这边不重复造轮子，而现在摆在我们面前的无法是第三方组件的选择。

Migrator.NET OR FluentMigrator

通过一些了解知道在.NET下的迁移组件，决定在二者选其一，我们毫不犹豫的选择了FluentMigrator，原因有下两点：

1.最后代码提交时间

FluentMigrator于8月份还有代码提交，而Migrator.NET最后一次提交时间在2013年。

2.作者

FluentMigrator的作者来自大名鼎鼎的ReSharper。

我们希望组件越稳定越好，而且出现问题还会得到解决，所以我们选择了FluentMigrator。

138张表如何迁移？

面对如此庞大的量如何顺利且快速的完成？

团队协作

一开始想每个人自行把负责的模块进行迁移，大家群策群力解决这次的任务。

在手工迁移了三个模块后我快崩溃了，几十张的表要跟数据库对来对去，是在hold不住，而且第一次完成之后还得检查一遍，对于我这种懒人来说无疑是种折磨。

己所不欲勿施于人，这时候站在团队成员的角度想了想我都不愿意做的事情他们会愿意做吗？

于是下定决定写一个代码生成器，在周末利用了一两个小时完成了这一个小东西。

代码生成器

实现的功能

1.根据数据库列生成WithColumn等代码

2.自动解析外键生成ForeignKey

3.根据ForeignKey对表关系进行排序

缺陷

当然因为时间问题还是有缺陷的，大家可以进行修复，问题不难。

删除表的优先级没有做处理

因为创建表和删除表的顺序正好是相反的，因为时间问题和复杂度比较简单也没有对此作单独的排序所以在生成的删除表代码需要人工倒序=_=。

使用方式

修改App.Config

ConnectionString：数据库连接字符串

OutputPath：生成路径

生成结果

创建表代码：

删除表代码：

写在最后

福州地区有需要找工作或者想换工作的“猿”吗？如果有可以沟通沟通联系联系呗。

代码生成器源码：点击下载

模块化之后的项目在正式环境中的数据迁移（含代码生成器）