期待已久的EF终于来了。
学完本篇文章，你将会掌握基于EF数据模型的完整开发流程。
本次将会完成EF数据模型的搭建和使用。
基于这个模型，将之前的示例添加数据库查询验证功能。
文章提纲
概述 & 要点
详细步骤
总结
概述 & 要点
下面是本文要点，正文部分会有详细介绍。
- EF架构图
- 新建基于EF的Data Model的约定
- 关于ORM的重要概念，和传统方式开发的区别
- EF开发的整体过程
详细步骤
- 新建文件夹，规划好代码摆放位置
- 创建相关类 (Data Model)
- 创建Initializer, 使用EF初始化数据库，插入示例数据
新建文件夹，规划好代码摆放位置
- 根目录下新建一个 ViewModels文件夹。
Models文件夹里面存放对应于数据库表的实体。
View中需要显示的数据和Models中实体模型不一定能对应上， 因此需要专门给View使用的自定义数据模型，我们称之为ViewModel , 放在ViewModels文件夹里面。
- 根目录下新建一个DAL 文件夹。
DAL 放置数据访问相关类。
NOTE 本文中放AccountContext.cs, AccountInitializer.cs
创建相关类(Data Model)
为了更加贴近真实情况，我们针对用户建立三个相关的类。
SysUser, SysRole, SysUserRole
这是用户权限管理RBAC (Role – Based Access Control)的一个典型模型, 更复杂的模型都可以在这个基础上进行扩展。
OK，下面我们就开始新建这个模型。
我们先去网上找个大致的关系图做参考，打开百度，输入 user role , 搜索图片。
挑一个类似的做参考。
NOTE 权限相关是系统管理范畴的，不涉及具体业务，我起名字的时候都加了Sys前缀，这样和业务区隔开来。
参考上面这个图建立 Data Model
SysUser Entity
SysRole Entity
SysUserRole Entity
对于上面几个类的约定和说明：
- EF 生成数据库时 , <navigation property name><primary key property name>这种形式的会成为外键. ( 约定 )
例如外键 SysUserID = SysUser(navigation property)+ID(SysUser的主键)
navigation 属性保存着其他的关联entity(entities)
示例中, SysUser和SysUserRole是一对多的关系, SysRole和SysUserRole也是一对多的关系.
如果是 "多", 属性类型就必须是list( 这里用的是Icollection )
创建 Database Context
前置条件：安装EF
打开 工具à库程序包管理器à程序包管理器控制台
输入 install-package entityframework
去MSDN上查看下EF的架构图：http://msdn.microsoft.com/en-us/data/aa937709
从上图可以看出，EF框架在底层是通过调用ADO.NET来实现数据库操作的。
多转一道弯性能和灵活性肯定会受到影响，所以本系列文章结束后同样也会给出MVC+ADO.NET的方案，大家可以根据需要选择。
NOTE
微软官方推出的ORM框架主要有Linq to SQL和Entity Framework.
EF是目前最新的，也是推荐配合MVC使用的框架。
实际操作前再补充一些重要概念：
如果不用ORM框架，我们一般这样来使用ADO.NET进行数据库开发：
- 将ADO.NET对数据库的操作封装到一个类里SqlHelper中
- 在DAL层调用SqlHelper
- 其他层再调用DAL进行数据库操作
使用ORM之后，以前面的SysUser为例：
O(Object) à 程序中的类 SysUser, 就是对象
R (Relation)à 数据库中的表
M(Mapping)à O和R的映射关系
ORM对传统方式的改进：
充当桥梁，实现了关系数据和对象数据的映射，通过映射自动产生SQL语句。
对常用的操作，节省了写SQL语句的步骤。
好了，现在必要的概念应该理解了吧，下面我们就进行实际的操作了。
创建类 AccountContext.cs , 让他继承自System.Data.Entity.DbContext， 我们用这个类完成EF的功能。
主要做下面三件事：
- 为每个entity set创建一个DbSet
在EF中，通常情况下一个entity set对应数据库中的一张表，一个entity对应表中的一行。
- 指定一个连接字符串
构造函数中的 base("AccountContext") 。
默认情况下和类名一样，即AccountContext，我们显式的给他指定出来。
- 指定单数形式的表名
>();
默认情况下会生成复数形式的表，如SysUsers
NOTE 表名用单复数形式看各自的习惯，没有明确的规定。有的公司表名全用单数，有的公司根据表的意思，有单数也有复数。
配合上面第2点，先把web.config中连接字符串给指定了。
如下图，贴着appSettings配置节上面添加。注意要web.config中要加上红字部分，不然会出错。
<connectionStrings>
<add name="AccountContext" connectionString="Data Source=.;database=MvcDemo;uid=sa;pwd=123456;AttachDBFilename=|DataDirectory|\MvcDemo.mdf;" providerName="System.Data.SqlClient"/></connectionStrings>
NOTE AttachDBFilename=|DataDirectory|\MVCDemo.mdf设定了数据库文件的存放位置：在项目根目录的App_Data文件夹下。
创建Initializer, 使用EF初始化数据库，插入示例数据
EF可以以多种方式建立数据库。
我们采用如下方式：
第一次运行程序时新建数据库，插入测试数据； model改变（和database不一致）时删除重建数据库，插入测试数据。
目前在开发阶段，不用管数据丢失的问题，直接drop and re-create比较方便。
等系列文章结束后会讲解生产环境中如何不丢失数据修改schema
下面我们就新建类AccountInitializer.cs来完成这个工作。
Seed方法用我们之前定义的database context(即AccountContext) 作为参数，通过这个context将entities添加到database中去。（就是我们前面说的桥梁作用）
从上面代码可以看出， Seed方法对每一个entity的类型（我们用了SysUser和SysRole, SysUserRole我们暂不添加）：
创建一个colletion à 添加到适当的 DbSet property à 保存到数据库。
NOTE 不一定要在每个entity组后面都调用SaveChanges方法，可以在所有组结束后调用一次也可以。这样做是因为如果写入数据库代码出错，比较容易定位代码的错误位置。
修改web.config, 通知EF使用我们刚刚写好的initializer类。
找到entityFramework配置节，添加下图方框处内容。
context 配置节中， type 的值对应 （context class的完整描述，程序集）
databaseInitializer 配置节中 ， type 的值对应 （initializer class 的完整描述，程序集）
NOTE ： 如果你不想EF使用某个context, 可以将下面方框处设置为true.
完成数据库查询验证
现在EF一切就绪.
运行程序，当第一次连接数据库时，EF比较model(AccountContext和entity classes) 和database. 如果两边不一致，程序将会drop and re-create数据库。
因为目前我们还没有连接数据库的操作，所以EF还没发挥作用。
现在我们完成前面的Login功能。
- 先做点小修改，在ModelsàSysUser.cs里面添加个Email字段。
同样DALàAccountInitializer.csàSeed里面示例数据也要增加这个字段
NOTE 添加一个Email是因为之前的登录页面填入的是Email值，后面将会输入Email和Password到数据库中进行比对。
- 打开Controllers à AccountController.cs
- Instantiate 一个database context 对象
- 修改HttpPost类型的Login Action，查询数据库进行比对。
NOTE
用过SQL的人都知道，学习SQL，最复杂的是查询，把各种查询学好了，基本就掌握70%以上了。
EF数据模型的数据操作也一样，重点是查询，下篇文章会展开讲。（从简单查询到条件、聚合、连接等复杂查询都会涉及到）
运行Login.cshtml页面，输入正确的和错误的登录信息验证下。
另外再检查一下数据库部分是否符合我们的预期：
- 打开数据库，发现MVCDemo这个数据库已经新建，示例数据已经插入。
- 打开项目的App_Data 文件夹，发现数据库文件已经存在。
