MVC5+EF6 入门完整教程八

本篇是相对独立的一篇，主要讲解不丢失数据进行数据库结构升级。

前面咱们讲解EF功能时，已经介绍过一种更新数据库的方式：

EF比较model和database，若是两边不一致，程序将会drop and re-create数据库。

本篇文章咱们会使用 code first migrations的方式。

这个功能可使你改变data model，在不drop and re-create数据库的状况下更新数据库的结构，将这些改变部署到生产环境中。

下面就着重介绍如何使用此功能。

文章提纲

• 前置条件
• 启用迁移功能
• 执行迁移
• 总结

前置条件

先回顾下以前EF修改模型的方式。

咱们事先配置好EF，每次数据模型改变的时候都会drop and re-create数据库。

例如你增长、删除、改变实体类，或改变DbContext类后，运行程序时将会自动删除已有的数据库，建立一个新数据库来匹配修改后的模型，一样也会根据Seed方法中内容新建test data.

这种保持database和data model同步的方法在开发阶段很方便。

若是已经部署到生产环境中就不行了, 例如表中扩充一些字段啥的， 原来的数据就不能丢失。

咱们禁用原来更新数据库的方式，将web.config中contexts配置节注释掉。

另外咱们不用原来数据，改下数据库名，这样能够生成一个新的数据库，方便作实验。

启用迁移

下面就启用Code First Migrations来解决数据库更新的问题。

1. 打开Package Manager Console

1. 连续输入以下指令：

   enable-migrations 和 add-migration InitialCreate

   enable-migrations指令：

   a.在项目根目录下建立了一个Migrations文件夹

   b.在Migrations文件夹下新建一个Configuration.cs文件。

   能够经过修改Configuration.cs来对Migration作一些配置（如加入一些测试数据等）

   Note

   若是前面没修改web.config的数据库名， 执行enable-migrations指令后，Migrations将会找到已有的数据库MVCDemo而后自动执行add-migration指令。

   相似咱们第三篇文章中讲到 DALàAccountInitilizer.cs类，Configuration类也包含一个Seed方法。

   当数据库新建或数据库结构更新后，这个方法会被调用，利用这个方法能够插入或更新test data.

2. 配置Seed方法

使用drop and re-create的方式时，由于每次model改变时数据库都会被删除，全部数据都会丢失，因此须要使用DALàAccountInitilizer.cs的Seed方法来插入测试数据。

使用Code First Migrations方式，当数据库改变时测试数据会保留，因此包含test data的Seed方法通常来讲是不须要的。

若是咱们要部署数据库到生产环境，事实上这种状况下咱们也不想Seed方法来插入测试数据到生产环境中。

生产环境中用到Seed方法的例子： 好比在咱们部署时得到了实际的初始化数据，如实际存在的组织部门这些初始化的信息。

咱们为了作实验方便，仍是插入一些测试数据。

先插入SysUser和SysRole

相似于前面文章提到的，Seed方法接收一个database context参数，利用这个参数添加新的实体到数据库中。

对每一个实体类型：

1. 新建一个实体集合
2. 添加到相应的DbSet属性
3. 保存更改到数据库中

若是你们还记得以前的文章能够发现有一点不一样，之前都是用Add方法，此次用了AddOrUpdate方法来插入数据。

sysUsers.ForEach(s => context.SysUsers.AddOrUpdate(p => p.UserName, s));

每次执行update-databse指令时都会执行Seed方法，通常来讲，每次迁移后，你不单单是插入数据，例如你想要插入的数据在你建立数据库的第一次迁移后已经在数据库中了，这种状况下更新原有数据就能够了。

AddOrUpdate正好能够解决这个问题：

若是数据不存在，插入数据；若是数据存在，更新这笔数据。

context.SysUsers.AddOrUpdate(p => p.UserName, s)

第一个参数p.UserName就是检查数据是否存在的主键。

咱们的测试数据中，假设UserName都不能重复。

做为比较，咱们添加SysUserRole实体类型的时候没有使用AddOrUpdate，直接人为判断是否存在，不存在再插入。

 

编译下项目，下面开始更新数据库。

执行迁移

前面执行 add-migration时，一样在Migrations文件夹里面，产生一个<timestamp>_InitialCreate.cs的文件。

里面两个方法，Up和Down:

Up方法建立数据库表，Down方法删除表。

public override void Up()

{

CreateTable(

"dbo.SysRole",

c => new

{

ID = c.Int(nullable: false, identity: true),

RoleName = c.String(),

RoleDesc = c.String(),

})

.PrimaryKey(t => t.ID);

 

CreateTable(

"dbo.SysUserRole",

c => new

{

ID = c.Int(nullable: false, identity: true),

SysUserID = c.Int(nullable: false),

SysRoleID = c.Int(nullable: false),

})

.PrimaryKey(t => t.ID)

.ForeignKey("dbo.SysRole", t => t.SysRoleID, cascadeDelete: true)

.ForeignKey("dbo.SysUser", t => t.SysUserID, cascadeDelete: true)

.Index(t => t.SysUserID)

.Index(t => t.SysRoleID);

 

CreateTable(

"dbo.SysUser",

c => new

{

ID = c.Int(nullable: false, identity: true),

UserName = c.String(),

Email = c.String(),

Password = c.String(),

})

.PrimaryKey(t => t.ID);

 

}

 

public override void Down()

{

DropForeignKey("dbo.SysUserRole", "SysUserID", "dbo.SysUser");

DropForeignKey("dbo.SysUserRole", "SysRoleID", "dbo.SysRole");

DropIndex("dbo.SysUserRole", new[] { "SysRoleID" });

DropIndex("dbo.SysUserRole", new[] { "SysUserID" });

DropTable("dbo.SysUser");

DropTable("dbo.SysUserRole");

DropTable("dbo.SysRole");

}

下面咱们就执行正式迁移。打开Package Manager Console

输入 update-database

update-database指令调用了Up方法来新建database的表（和data model entity set对应）, 而后调用Seed方法来填充测试数据。

这个时候测试下程序，打开数据库看下，彻底符合咱们的预期。

 

再进一步，咱们添加一个表Test

先添加一个Model

修改AccountContext.cs, 增长一个data model entity set

执行add-migration AddTestTable和update-database, 完成数据库表的添加。

去数据库中检查，发现已经多了Test这张表了。

最后再检查下新产生的配置文件。

你们如今应该能充分理解到add-migration时产生的文件的做用了吧。

总结

本次咱们主要讲解了数据库迁移/升级的问题。

主要分为 启用迁移（enable-migrations） 和 执行迁移(add-migration, update-database) 两大步骤。

启用迁移：产生迁移相关文件夹Migrations和文件夹中相关的配置文件。

执行迁移：产生相关的迁移更改文件并执行更改。

请充分理解本篇文章所讲的例子, 后面文章会屡次用到add-migration.