关于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/