Code First 代码迁移是为了时刻保持领域模型与数据库架构同步,Entity Framework 作为幕后辛勤的劳动者，通过一定程序的自动化使这一切变得更容易。
代码迁移命令
在Code First 模式中进行迁移（Migrations）常见的命令有如下4个：
Enable-Migrations：表示在项目中启用代码迁移Add-Migrations：表示对已挂起模型改变搭建基架，也就是说在上次钱以后对模型进行了更改，以此为下一次迁移搭建基架，此时生成的模型状态为挂起状态（或者称为待定状态）。Update-Database：表示通过 Add-Migrations 命令将挂起的模型迁移应用到数据库中并保持模型同步。Get-Migrations：表示显示已应用到数据库的迁移。
命令使用
- Enable-Migrations
运行Enable-Migrations 未指定任何其他参数，此时生成的迁移目录将是 Migrations，迁移的项目为包管理器控制台中的默认项目且迁移目录和上下文包含在同一项目中。
当执行带有参数的命令时：
Enable-Migrations -ContextTypeName EfDbContext -MigrationsDirectory JeffckMigrations
- Add-Migrations
此命令一般用在我们修改了POCO后，需要执行该命令。将POCO的变更信息采用代码的方式记录下来，方便后面同步更新到数据库中。
语法：
Add-Migrations 自定义脚本名称
语法：
Add-Migration First -IgnoreChanges
表示将忽略当前模型的改变。
- Update-Database
通过运行 Update-Database 而未指定其他任何参数，说明更新数据库到最近的迁移。
运行命令：Update-Database -Script -SourceMigration $InitialDatabase
该命令会生成一个脚本，可以将目前任何版本的数据库升级到最新版本。生成的脚本包含检查_MigrationHistory表并且应用更改的逻辑。
迁移的本质
- 实体框架啊审查映射的解决就方案中的模型。
- 实体框架检查解决方案中的现有迁移，并确定自上次迁移以来所做的更改。
-构建更改的“脚本”，实体框架就更改“脚本”添加到迁移文件中。 - 迁移文件以时间戳和更改的简要名称说明。
每一个迁移脚本都对应数据库中“_MigrationHistory”表中的一条数据。
_MigrationHistory这个表是从哪里来的？有什么用？
_MigrationHistory 表有 Entity Framework 自动创建，用于跟踪已应用于数据库的状态更改。当实体框架将迁移应用于数据库时，会查询_MigrationHistory 表并将其与存储在已编译项目中的迁移进行比较，并应用缺少的迁移。
当我们在NuGet管理器控制台运行Update-Database 时，发生了什么呢？
- 它始终按照附加到迁移名称开头的时间戳的顺序来查看迁移。
- 数据库中不存在（但存在于代码中）的任何迁移都将按照时间戳的顺序应用于数据库。
- 再次创建当前领域模型的哈希值，并与应用于数据库的最后一次迁移的散列模型值进行比较（存储在_MigrationHistory表中）。
我们如何解决团队协作而导致的迁移问题呢？
团队可以采用自动迁移方式解决该问题，可是这样会导致后期难以维护，所以我们采用手动去维护，同时保持同时迁移的记录可追踪。采用以下4步骤进行：
（1）、回滚模型
语法：
Update-Database -TargetMigration 迁移名
采用此命令，可以将当前数据库回滚到指定迁移时的状态。
（2）、重命名和更新时间戳
（3）、更新模型
强制重新检查模型改变
语法：
Add-Migration 迁移名称 -Force
（4）、迁移模型
对于EF迁移，我们需要记住以下三点：
- EF 实体框架使用_MigrationHistory表来追踪应用于数据库的更改。
- EF实体框架创建项目中当前模型状态的哈希值，并将其与_MigrationHistory表中的模型转台存储进行比较，以确定数据库是否为当前状态。
- 进行迁移时，始终按照时间戳（升序）的顺序同步到数据库。
