写在前面：
EF 中 Code First 的数据迁移网上有很多资料，我这份并没什么特别。Code First 创建视图网上也有很多资料，但好像很麻烦，而且亲测好像是无效的方法（可能是我太笨，没搞成功），我摸索出了一种简单有效的方法，这里分享给大家。
EF是Entity Framework（实体框架）的简写，是微软出品的用来操作数据库的一个框架，会ASP.NET MVC的朋友对他肯定都不陌生。由于学艺不精，我对EF存在一疑虑，就不以【提问】的方式来问了，我以【总结】的方式来表达，如果总结有误的地方，还请看到的大神可以指正，并赐教我正确的认知，万分感谢。
EF有三种使用方式：
1) Db First 数据库优先
2) Model First 模型优先
3) Code First 代码优先
上图中，前三种分别是DbFirst、ModelFirst和CodeFirst，而第4种也是CodeFirst。
一、DbFirst、ModelFirst必须从app.config/web.config中读取连接字符串，简直无情
不知道是我功底太差，还是微软真的就是这么设计的，我发现一个问题：DbFirst和ModelFirst这两种模式，居然只能从App.config/Web.config中读取数据库连接字符串，这是一个致命的问题，这意味着连接字符串不能被加密必须暴露给客户看（如果你是窗体应用程序的话）。（感谢 @lcs-帅 指正这一点） 这意味着我们必须要 这样（利用ASP.NET加密和解密Web.config中连接字符串） 来对我们的连接字符串进行加密，好像有点太复杂了。
如果不利用上面红色大字中提到的方法，那我们大概可以有两种方式读取数据库连接字符串，第一种是在App.config/Web.config中读取：
<connectionStrings>
<add name="Model1" connectionString="data source=(LocalDb)\v11.0;initial catalog=数据库名;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="..略.." />
</connectionStrings>
这种方式不太好，因为如果是窗体应用程序的话，等于就用明文告诉了别人你的数据库密码了。当然，你也可以对这一段字符串进行加密，就像这样：
<connectionStrings>
<add name="Model1" connectionString="ZGF0YSUyMHNvdXJjZSUzRCUyOExvY2FsRGIlMjklNUN2MTEuMCUzQmluaXRpYWwlMjBjYXRhbG9nJTNEJXU2NTcwJXU2MzZFJXU1RTkzJXU1NDBEJTNCaW50ZWdyYXRlZCUyMHNlY3VyaXR5JTNEVHJ1ZSUzQk11bHRpcGxlQWN0aXZlUmVzdWx0U2V0cyUzRFRydWUlM0JBcHAlM0RFbnRpdHlGcmFtZXdvcms=" providerName="..略.." />
</connectionStrings>
而当你像上面这样对数据库连接字符串进行加密，此时你就等同于选择了使用第二种方式读取连接字符串了，第二种读读取数据库连接字符串的方式是：
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["Model1"].ConnectionString; //可选
connStr = 解密(connStr); //可选
Model1 db = new Model1(connStr); //第二种设置数据库连接字符串的方式
这第二种方式的前2句代码是可选的，也就是说你不一定要从Web.config/App.config中读取数据库连接字符串，你也不一定要对数据库连接字符串进行加解密。
这第二种方式最重要的是第3句代码，也就是说你可以使用一个字符串变量来做为数据库连接字符串，这意味着你不一定要从Web.config/App.config中读取数据库连接字符串。
然而！可惜的是：在DbFirst和ModelFirst中，并不支持第二种设置数据库连接字符串的方式，这也就意味着DbFirst和ModelFirst的应用场景大打折扣！
在DbFirst或ModelFirst中，调用以下代码会报错，因为只有一个无参构造方法：
也许你（曾经我）自做聪明的想到一些办法，写一个【部分类】为 DbContext 添加一个有参构造函数：
事实证明是自做聪明，当你去操作任何一张表的时候，就报这个错误：
当你（我）看到这一个错误提示的时候，终于认命了：在DbFirst和ModelFirst中，数据库连按字符串只能写在App.config/Web.config中，简直无情。
二、CodeFirst 可以从代码中读取数据库连接字符串，不必从Web.config/App.config中读取。
要在CodeFirst中对连接字符串进行加密，首先要添加一个带参构造函数，就像这样：
public Model1()
: base("name=Model11")
{
}
public Model1(string nameOrConnectionString)
: base(nameOrConnectionString)
{
}
然后就这样：
string connStr = System.Configuration.ConfigurationManager.ConnectionStrings["Model1"].ConnectionString; //可选
connStr = 解密(connStr); //可选
Model1 db = new Model1(connStr); //第二种设置数据库连接字符串的方式
从配置文件中读取出加了密的连接字符串，再进行解密，最后应用于 DbContext 之中。
在CodeFirst中进行这样的操作程序不会报错，简直有爱。
三、【空 Code First 模型】与【来自数据库的 Code First 】殊途同归，是一样的
关于Code First，有两个可以选择，下图中的最后两个：
这两者是殊途同归，是一样的。
【空CodeFirst模型】就是新建一个空的模型，然后自己写实体类代码，根据这些实体类代码来生成数据库，生成数据库了之后，就与【来自数据库的CodeFirst】是一样的。
【来自数据库的CodeFirst】就是根据从数据库中选择的一些表/视图来生成实体类代码，这些自动生成的代码和你自己手写是一样一样的，也就是与【空CodeFirst模型+手写实体类代码】是一样的。
然而，并不完全是！慢慢聊吧。
四、数据迁移
数据迁移，就是实体模型类发生变化之后（比如多一个字段，字段类型改变，或者多了一个实体类），数据库的表结构也跟着一起变化的过程。
4.1 为什么要使用数据迁移
因为模型和实际的数据库结构可能会不一样，不一样的话程序运行就会有问题，所以需要使用数据迁移这个功能来帮助我们解决问题。
用一个例子来说明，创建控制台应用程序，创建【空CodeFirst模型】：
//数据库Model1
public class Model1 : DbContext
{
public Model1() : base("name=Model1") { }
public virtual DbSet<MyEntity> MyEntities { get; set; }
}
//实体类 (对应表：MyEntities)
public class MyEntity
{
public int Id { get; set; }
public string Name { get; set; }
}
修改数据库连接字符串，改成一个我们熟悉的数据库服务器名，以免数据库新建了之后，找不到在哪里：
<add name="Model1" connectionString="server=服务器名;uid=用户名;pwd=密码;database=新的数据库名;" providerName="System.Data.SqlClient" />
然后在Main方法中随便访问一下这个实体类：
using (var db = new Model1())
{
//随便访问一下 MyEntities 表，以便让 EF 自动创建此表
var x = db.MyEntities.Find();
}
运行程序，就会得到一个新的数据库，新数据库里面有一个新表 MyEntities。（还有另一个叫 __MigrationHistory 的表，是用于记录代码迁移的历史记录，也是代码迁移模式的开关，后面慢慢聊）
到这里为止，一切都正常。
现在，我们再添加一个年龄Age字段：
//实体类 (对应表：MyEntities)
public class MyEntity
{
public int Id { get; set; }
public string Name { get; set; }
//添加了年龄字段
public int? Age { get; set; }
}
这时，再运行程序，就会报一个错误：
错误的大概意思就是：模型与实际数据库结构不一致，需要使用 Code First 中的数据迁移功能来解决问题。
4.2 数据迁移的用法
当模型与实际数据库结构不一致时，就需要使用数据迁移。数据迁移我们只需要掌握三个方法就可以了，它们分别是：
1) 在当前项目中启用数据迁移 Enable-Migrations
2) 添加迁移版本 Add-Migration 版本名称
3) 更新数据库 Update-Database
首先第一步，需要在当前项目中启用数据迁移，打开【视图->其它窗口->程序包管理器控制台】快捷键是 Alt+V，E，O，然后输入命令：
Enable-Migrations
这样就可以在当前项目中启用数据迁移了，其效果是项目中会多出 Migrations 文件夹以及一些代码：
Migrations 这个文件夹就是数据迁移的相关文件夹，做为初学者，不要乱动里面的代码。
由于我们的模型已经发生了改变，所以需要添加一个新的迁移版本，在程序包管理控制台执行如下命令：
Add-Migration v1
其中的v1表示版本号，自己随便取一个名字就可以了。此时，项目中多出一个文件：
这个文件的代码是：
//版本 v1
public partial class v1 : DbMigration
{
//版本升级
public override void Up()
{
//向 MyEntities 表添加 Age 字段
AddColumn("dbo.MyEntities", "Age", c => c.Int());
} //版本降级
public override void Down()
{
//向 MyEntities 表删除 Age 字段
DropColumn("dbo.MyEntities", "Age");
}
}
代码中的注释是我写上去的，大概的为大家解释了一下是什么意思。到这里为止，数据库依然没有发生变化。
想要数据库发生变化，多出一个 Age 字段，那就要用到第三个命令：
Update-Database
执行成功之后，数据库就多出一个 Age 字段了。
此时，再运行程序，程序就不会报错了。因为此时的模型与实际数据库结构已经一致。
至此，例子已演示完毕。
这里有一个非常非常非常重要的细节，要注意：
如果你使用了 new Model1(connStr) 自定义数据库连接字符串，在使用数据迁移的命令时，所访问的数据库是你 web.config/app.config 中配置的数据库，并不是你自定义连接的那个数据库。
这是一个巨坑，一定要注意：
使用了自定义数据库连接字符串时，虽然 web.config/app.config 中的明文数据库连接字符串并不一定要被发布，但在开发时也一定要在里面填写上正确的数据库连接信息。
五、关闭数据迁移
数据迁移的开启与关闭分两个层面来说：
1) Visual Studio 项目是否开启了数据迁移
2) SQL Server 数据库是否开启了数据迁移
对于项目中是否开启了数据迁移，识别方法是：有没有 Migrations 这个文件夹以及里面的类文件。如果有就表示开启了，没有就没开启。
对于数据库中是否开启了数据迁移，识别方法是：有没有 __MIgrationHistory 这个表。如果有就表示开启了，没有就没开启。
以下讨论的数据迁移开启和关闭，都是指数据库中数据迁移的开启和关闭。
实际上 Code First 又有两种分支用法：
1) 数据库中 启用了数据迁移的 Code First
2) 数据库中 关闭了数据迁移的 Code First
这个开关并不在于你的项目中有没有 Migrations 这个文件夹，而在于：你的数据库里面，有没有 __MigrationHistory 这个表。
当你使用【空 Code First 模型】创建出来的数据库，默认就是开启了数据迁移的，关闭它的方法自然就是删除 __MigrationHistory 这个表。
而你使用【来自数据库的 Code First】默认这个数据库就是关闭了数据迁移的 ，用一个例子来说明一下吧。
示例：
先确保你的数据库实例中有一个数据库，这个库里面有一些表，比如 Student 表，并且这个库没有 __MigrationHistory 这个表。
然后新建控制台程序，并创建【来自数据库的 Code First】，选择 student 表，自动产生模型代码和上下文类的代码：
//这是自动产生的代码 （我进行了删减）
public partial class Model1 : DbContext
{
public Model1(): base("name=Model1") { }
public virtual DbSet<student> student { get; set; }
}
//这是自动产生的代码 （我进行了删减）
public partial class student
{
public int id { get; set; }
public string name { get; set; }
}
然后在 Main 方法里随便调用一下，看看有没有问题：
using (var db = new Model1())
{
//随便调用一下，看看有没有问题
var x = db.student.Find();
}
因为此时的模型与实际数据库结构是一样的，运行结果当然不会有问题了。
现在，我们修改一下模型，在学生实体类中添加一个身份证的字段：
public partial class student
{
public int id { get; set; }
public string name { get; set; }
//添加身份证 idcard 字段
public string idcard { get; set; }
}
此时，我们再运行程序，程序报错了，但报的错误并不是让我们进行数据迁移：
报的错误是：列名 'idcard' 无效。
这就是数据库中关闭了数据迁移的 Code First 的行为表现，不会提示你（要求你）进行数据迁移。
没有了数据迁移，我们怎样才能让模型和实际数据库表结构一样呢？
很简单，你自己手动在数据库 student 表中添加一个 idcard 字段不就可以了吗。
确实，当我们手动添加了 idcard 字段之后，再运行程序，程序就不报错了。
小总结：
1) 使用【空 Code First 模型】创建出来的数据库默认是开启数据迁移的，我们只需要删除 __MigrationHistory 表就可以关闭数据迁移。
2) 使用【来自数据库的 Code First】这种方式，数据库默认就是关闭了数据迁移的。
3) 在数据库中关闭数据迁移的优点是：
你可能并不熟悉数据迁移是个什么鬼，那不如就让它见鬼去吧。关闭它，会让你进入你熟悉世界，通过手动改写实体类，手动改数据库表结构，来同步模型与实际表结构，挺好！
六、在关闭数据迁移的模式下，在 EF 实体模型中创建视图
数据库关闭了数据迁移的情况下，要在 EF 实体模型中创建视图，实在是太简单了。
你就编写一个实体类来当成视图，比如 v_student，你就把它当成是一张表一样来编写：
//我想写一个视图，先别急，先当它是一张表
public partial class v_student
{
public int id { get; set; }
public string name { get; set; }
//姓
public string first_name { get; set; }
}
public partial class Model1 : DbContext
{
public Model1(): base("name=Model1") { }
public virtual DbSet<student> student { get; set; }
//我想写一个视图，先别急，先当它是一张表
public virtual DbSet<v_student> v_student { get; set; }
}
然后，在 Main 方法中访问这个视图，看看有没有问题：
using (var db = new Model1())
{
//访问一下这个视图，看看有没有问题
var x = db.v_student.Find();
}
运行。当然会有问题啦，会报这个错误：
注意到了吗，它只是说 v_student 无效，并没有说让我们做什么数据迁移。
好吧，难道我们要傻傻的去创建一个 v_student 表吗？ 难道不可以创建一个 v_student 视图？
当然可以，我们来创建一个视图吧，在数据库中执行以下SQL语句：
create view v_student
as
select id,name,substring(name,1,1) first_name from student
go
然后，测试运行程序，程序不报错了。任务完成。
七、在开启据迁移的模式下，在 EF 实体模型中创建视图
也许你比较欣赏在数据库中开启了数据迁移的这种模式，在数据库中开启了数据迁移的模式下，能不能创建视图呢？如果可以，又如何创建视图呢？
网络上你可以搜索到很多 Code First 中创建视图的方法，这些方法都是指数据库中开启了数据迁移的 Code First 下的方法，但好像都挺麻烦的，反正我照着做并没有做出来。
然后我摸索了一下，找出一种简单又实用的方法，这里分享给大家。没错，这一段落才是本文最有价值的部分。
依然用例子来说明：
上接第四节【数据迁移】的例子，我们来添加一个 V_MyEntity 的视图，代码如下：
//我想写一个视图，先别急，先当它是一张表
public class V_MyEntity
{
public int Id { get; set; }
public string Name { get; set; }
//姓
public string First_Name { get; set; }
}
public class Model1 : DbContext
{
public Model1() : base("name=Model1") { }
public virtual DbSet<MyEntity> MyEntities { get; set; }
//我想写一个视图，先别急，先当它是一张表
public virtual DbSet<V_MyEntity> V_MyEntity { get; set; }
}
然后在 Main 方法随便访问一下这个视图，看看可不可以：
using (var db = new Model1())
{
//访问一下 V_MyEntity 视图，看看可不可以
var x = db.V_MyEntity.Find();
}
运行程序，自然是报错了：
因为模型与实际数据库表结构不一致，所以报错了，由于数据库中开启了数据迁移的，所以会提示你（要求你）进行数据迁移。
此时，如果按照正常的步骤来进行数据迁移，我们将得到 V_MyEntity 这个表，这当然不是我们想要的结果，我们是要 V_MyEntity 视图啊。
那就需要在数据迁移的过程中，做一点手脚，具体如下。
在程序包管理器控制台中输入以下命令，以创建一个新的迁移版本：
Add-Migration v2
其中的 v2 表示版本号，其实可以随便乱写也行，只是个版本名字而已。
刚刚的操作使我们多出一个文件，内容如下（其中的中文注释是我写的，不是生成的）：
//代码迁移版本：v2
public partial class v2 : DbMigration
{
//版本升级
public override void Up()
{
//创建表
CreateTable(
"dbo.V_MyEntity",
c => new
{
Id = c.Int(nullable: false, identity: true),
Name = c.String(),
First_Name = c.String(),
})
.PrimaryKey(t => t.Id); }
//版本降级
public override void Down()
{
//删除表
DropTable("dbo.V_MyEntity");
}
}
我们当然不想要创建表啦，我们要创建视图，那就把这个文件改一改，改成如下这个样子（本文最最最重要的环节）：
//代码迁移版本：v2
public partial class v2 : DbMigration
{
//版本升级
public override void Up()
{
//创建视图（本文最最最重要的环节）
Sql(@"create view V_MyEntity as select id,name,substring(name,1,1) first_name from MyEntities");
}
//版本降级
public override void Down()
{
//删除视图
Sql("drop view V_MyEntity");
}
}
改好之后，再执行数据迁移的最后一个命令，更新数据库：
Update-Database
这个时候，我们发现数据库没有多出一个 V_MyEntity 的表，而是多出了一个 V_MyEntity 的视图，目的达到。
最后我们再运行程序，程序也没有再报错了，目的妥妥的达到。
八、在【来自数据库的 Code First】中开启数据迁移
先要复习几个问题：
1) 用【空 Code First 模型】创建的数据库，默认就是开启数据迁移的。
2) 用【来自数据库的 Code First】这种方式，其数据库默认是关闭数据迁移的。
3) 判断一个数据库有没有启用数据迁移，办法是：检查有没有 __MigrationHistory 表。
也许虽然你比较欣赏数据库中开启了数据迁移的这种模式，但是无奈你已经有一个数据库啦，数据库里80多张表也已经创建好啦，那我们当然要用【来自数据库的 Code First】，来帮助我们自动生成这80多个实体类啦。
可是，对于一个已经存在的数据库，我们能开启这个数据库的数据迁移模式吗？答案当然也是可以的，具体操作如下。
比如我们导入了一个Student表：
//我进行了删减
public partial class Student
{
public int Id { get; set; }
public string Name { get; set; }
}
//我进行了删减
public partial class Model1 : DbContext
{
public Model1() : base("name=Model1") { }
public virtual DbSet<Student> Student { get; set; }
}
然后二话不说，直接在项目中开启代码迁移（请注意这只是在项目中开启代码迁移，并没有在数据库中开启代码迁移）：
Enable-Migrations
然后再二话不说，创建一个迁移版本：
Add-Migration v1
添加了迁移版本之后，会自动产生一个版本文件，内容如下（中文注释是我写的，不是自动生成的，略也是我删减的）：
//数据迁移版本名称：v1
public partial class v1 : DbMigration
{
//版本升级
public override void Up()
{
//建表
CreateTable("dbo.Student",..略..);
}
//版本降级
public override void Down()
{
//删表
DropTable("dbo.Student");
}
}
然后再二话不说，执行更新数据库的操作（这等于是一口气把数据迁移的三个命令挨个打了个遍）：
Update-Database
然后就报错了：
错误提示数据库已经有Student这个表了，这个问题怎么解决呢？很好解决，办法就是找到之前那个版本文件，把版本升级Up()方法中的代码全部注释掉，如下：
//数据迁移版本名称：v1
public partial class v1 : DbMigration
{
//版本升级
public override void Up()
{
//建表
//CreateTable("dbo.Student",..略..); //注释掉这些代码是重要环节
}
//版本降级
public override void Down()
{
//删表
//DropTable("dbo.Student"); //注释掉这些代码是重要环节
}
}
注释掉之后，再执行 Update-Database ，这次就不报错了。
此时，数据库中多了一个 __MigrationHistory 表，这表示数据库的数据迁移功能已开启，目的已达到：
最后，为了将来考虑，最好将刚刚注释的代码又取消注释，这完全不影响你之后的使用。
总结：
1) EF 中只有 Code First 模式支持 new Model1(这里写连接字符串)，也就是说可以对其进行加密，这使得 Code First 成为大部分情况下的最佳选择。
2) Code First 中，当模型与实际表结构不一致时，程序会报错，我们有两种方式来使他们一致，一是手动修改模型代码和表结构，二是使用数据迁移功能。
这两种方式，不是你想选哪一种就选哪一种的，取决于一个关键因素：数据库是否开启了数据迁移
3) 数据迁移的开启，分两个层面，一是项目的数据迁移开启，二是数据库的数据迁移开启，前者并不怎么重要，后者决定了你需要手动还是自动来使模型与实际表结构一致。
项目中如果包含Migrations文件夹并且里面有相关的类，说明项目已开启了数据迁移。
数据库中如果有 __MigrationHistory 表，说明数据库已开启了数据迁移。
4) 删除数据库中的 __MigrationHistory 表，也就关闭了数据库中数据迁移功能，关闭数据迁移的目的是：
你可能并不熟悉数据迁移是个什么鬼，那不如就让它见鬼去吧。关闭它，会让你进入你熟悉世界，通过手动改写实体类，手动改数据库表结构，来使模型与实际表结构一致，挺好！
5) 我的建议是：不要关闭数据迁移，还是可以尝试学习一下数据迁移模式的。在程序包管理器控制台下，使用以下三个命令就可以使用数据迁移模式了：
*) 在项目中启用数据迁移 Enable-Migrations
*) 创建迁移版本 Add-Migration 版本名称
*) 更新数据库 Update-Database
6) 在数据库关闭数据迁移的情况下，创建视图的方式与创建表一样，写好实体类 V_ABC 之后，再到数据库里创建 V_ABC 的视图就行了。
7) 在数据库开启数据迁移的情况下，创建视图的方式是先写好 V_ABC 实体类，再添加迁移版本，然后在迁移版本的代码中注释创建表 V_ABC 的代码，改为创建视图 V_ABC 的代码，最后执行数据迁移中的更新数据库命令即可。
8) 巨坑：当你在执行数据迁移的三个命令时，它们永远是在 Web.config/App.config 中读取连接字符串！别误以为是 new Model1(这里的字符串) 啦。