关于EF中使用Migrations的一些小提示

在运行正常的状况下，EF的数据迁移功能很是强大。可是当它出现情况时，试图找到问题发生的缘由时一般都很让人郁闷（无法调试，提示信息很模糊等等缘由）。我花了不少时间来确保在个人迁移能工做正常，而后我整理了一些经验给你们分享一下:

1. 不要使用自动迁移（Automatic Migrations）

   自动迁移很适合演示环境或者快速验证模型等，可是在生产环境中就不太适合了。如下是否是用自动迁移的一些缘由：

   1. 自动迁移不能产生惟一标示，因此两次迁移过程当中不能产生差别化脚本，也就不能应用于其余环境，尤为是生产环境须要使用脚本进行迁移的时候。
   2. 自动迁移不会显示数据库发生了什么更改，也不提供单独的备份方法。
   3. Automatic Migrations are applied using the same ‘Update-Database’ command that also runs the Code-Based migrations (side effect free!). When mixing Automatic and Code-based migrations a simple ‘Update-Database’ to run Code-based migrations may also generate Automatic ‘ghost’ scripts against the database.

   下面是如何关闭自动迁移的方法：

2. 了解_MigrationHistory 表（启用迁移后在数据库中自动生成的迁移历史记录表）

   _MigrationHistory表提供了有关数据库的元数据，最重要的是它显示了那些迁移已经应用。在某些时候须要手动从这里删除记录，默认状况下它是一个系统表，但能够进行其余配置

3. 迁移并非只能“升”，它也能“降”

   每个迁移都有相应的升级或者降级的概念，当升级的时候，数据库将会应用迁移，当降级的时候，目标数据库会撤销相应的迁移。了解降级时目标数据库中结构和数据发生了什么和升级同样重要，保险起见，应该把它做为一项应急计划，确保发生问题能够轻松处理。

4. 若是你想从新生成迁移计划（“re-scaffold”），确保先撤销迁移。

   ‘Re-scaffolding’将会从新产生现有迁移的内容并添加一些新的改动进去。

   若是迁移已经应用到数据库，那必须先撤销迁移，而后再从新生成迁移文件。（使用update-database -target:xxxMigrationName）。若是没有撤销，迁移文件将会被修改，下次数据库迁移就会出现问题（可能就无法回退了）

5. 绝对不要再撤销迁移以前，删除迁移文件。

   首先迁移是能够回退版本的，若是在撤销迁移以前删除迁移文件，数据库将陷入无效状态。若是在后续继续添加迁移文件，可能会产生迁移问题（好比，新的迁移文件包含上一次迁移到内容，执行update-databse时会提示，更改已经存在）

6. 了解数据表关联处理（包括Fluent API）

   下面的代码很难理解么?

   对我来讲是的。不管如何配置数据表之间关系的时候必定要了解Fluent API的相关知识，能够在下文学习 configure the correct relationship

7. 查看迁移代码

   为何？难道是生成的迁移代码有问题么？其实并非。我在每次生成都要之后检查一下迁移文件，大多时候只是确保是关系配置的是否正确或者有没有遗漏了什么。

8. 完全恢复到初始状态，而后再回来

   常常检查一下迁移文件与数据库是否匹配，它们是否健康。一个方法是撤销全部迁移使其回到数据库的初始状态，而后再使用“Update-database”回到如今。比较适合使用单元测试自动完成。

9. Relax

   Learning Migrations can be a frustrating time suck. Don’t punch your monitor. Instead take a breather and relax, then come back to it. It is an investment, but when mastered it will pay dividends to your team and process.

   参考文档：https://elegantcode.com/2012/04/12/entity-framework-migrations-tips/