作者：汪鹏
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
你必须掌握的Entity Framework 6.x与Core 2.0试读：
前言
本书背景在Web开发中，ASP.NET MVC使用相当广泛，与之呼应的是使用ORM框架Entity Framework作为概念上的数据访问层，目前有些互联网招聘公司招聘时会明确要求熟练掌握Entity Framework。很多人对Entity Framework嗤之以鼻，不可否认，Entity Framework的性能确实是一个令人头疼的问题，但是还未到弃用的地步，大部分情况下还是我们的认识太浮于表面，没有深究原理，看清其本质。微软为我们封装了一切，我们只需进行傻瓜式的操作即可，但是最终带来的却是疯狂吐槽，请深入思考自己对Entity Framework是否有足够了解。笔者看过并搜索过很多关于Entity Framework和Entity Framework Core的博客，发现大部分内容介绍的太过浅显，学习一门新技术需要的是细嚼慢咽而非囫囵吞枣。对于中文版的Entity Framework和Entity Framework Core，市面上几乎没有一本著作进行相关介绍，导致很多人都是跟着别人的脚步笼统地学着，且一知半解、不知所云。基于以上几点，笔者打算尽最大的能力分享自己所理解的Entity Framework和Entity Framework Core，让大家能够循序渐进并系统地学习。本书特点
本书中Entity Framework和Entity Framework Core的内容完全不是从官方网站摘抄和翻译而来，如果你看过官方网站的目录介绍就会发现和笔者所列举的目录截然不同，从基础到进阶都经过笔者的精心编排，同时一切内容都不会蜻蜓点水似的泛泛而谈，均结合实际小型案例有理有据论证而来，掌握基础是必备前提，在完善基础的充分条件下，你会进一步深入基础。原理是必要条件，在掌握原理的条件下，从吸收到消化才是最终的归宿。如果你在实际项目中正在用Entity Framework 6.x，相信Entity Framework 6.x的内容会对你有进一步提高，如果你还在担心Entity Framework 6.x的性能，那么可阅读Entity Framework Core 2.0的内容，相信会让你刮目相看。本书读者
本书Entity Framework 6.x的内容适合想快速提高的初学读者、想基础拾遗的回炉读者、想进一步提高的进阶读者，而Entity Framework Core针对已跨平台的.NET Core应运而生，对于想要学习新技术的初学读者和已在项目中应用而需进一步深入的进阶读者均具有很强的参考和学习价值，同时高等院校和.NET技术培训机构也可选择本书作为参考教材。代码、勘误和支持
本书中的实例代码已上传至Github上（https://github.com/wangpengxpy）。
虽然笔者耗费大量时间对书稿进行反复的修改和推敲，但是水平有限，仍难免有疏漏之处，为了使本书能够更好地为读者服务，如果有问题，可通过QQ邮箱（2752154844@qq.com）与笔者的博客（http://www.cnblogs.com/createmyself）与本人联系。笔者将竭力解决所有问题，并向你的指正致谢。致谢
感谢夏毓彦编辑以及出版社其他人对本书所做的工作，正是你们的贡献使得这本书得以出版。你们所做的工作提升了本书的质量和准确性，使本书的品质能够得到保证，也让笔者更加有信心将自己对技术的理解展示给需要的读者。
写好一本书所投入的精力和时间无法估量，没有家人的支持和女友的理解，这本书不可能面世。感谢我的父亲、母亲、哥哥、姐姐，他们永远是我归宿的港湾，是我人生的支点和明灯，谢谢他们恒久不变的支持。特别感谢我的女友刘瑶，因为写作本书花费了大量时间而忽略了对她的关心，感谢她的体贴入微。现在，本书算是告一段落，终于有时间去多陪陪她了。
当然，最重要的是感谢一直以来关注笔者的同行技术者，是他们的鼓舞和肯定使得笔者在技术路上走得更远，感谢博客园给予的平台，让笔者能够学习和分享自己的见解，同时也感谢选择本书的读者，相信本书能够让你有所收获。汪 鹏2018年1月—·第一篇·—Entity Framework 6.x基础第1章Entity Framework的发展1.1 Entity Framework版本介绍
Entity Framework是一个Object/Relational（对象映射）Mapping实体框架，简称为ORM，可以在SQL Server、Oracle、DB2、MySQL等数据库上使用。我们可以将数据作为业务对象和实体来进行处理，开发者可以使用LINQ查询，然后使用C#面向对象语言来操作和检索数据。表1-1所示为Entity Framework的发展历程。表1-1 Entity Framework的发展历程1.2 Entity Framework领域建模方式
一个业务领域由各个实体和各个相互关联且有各自的属性和行为的实体组成，每个实体都有其状态和验证规则需要维护，Entity Framework实体框架设计的出现就是为了允许开发人员着重关注业务领域，开发人员就实体来建模。它产生的目的是为了解决企业快速开发和迭代出市场所需要的系统或者软件。下面我们介绍Entity Framework中的三种领域建模方式。1.2.1 Code First
Code First可以通过C#或者VB.NET来描述这些模型，然后通过类来创建数据库，这些类简称为POCO（Plain Old CLR Object）。POCO来源于Java中的POJO，其中的J为Java，POJO是由马丁·福勒（Martin Fowler）和其他人一同提出的概念，以反对在20世纪20年代早期受到欢迎的JavaBeans。POJO概念提出的主要目标是显式域可以被成功建模，而不会带来与执行环境相关的复杂表（而JavaBeans在其早期版本中带来了很多），同时执行环境与域建模完全无关。由于POJO不能在.NET中使用，因此有了具备POJO相同语义的POCO，同时微软也从未引入过相同的概念，POCO中的C是指在.NET Framework的公共语言运行时（Common Language Runtime，CLR）中创建的一个简单对象。非POCO另一个很好的例子在EF 4.0之前的版本中。EF 4.0之前生成的每个类都是从EntityObject基类继承而来的，因此带来了许多特定于Entity Framework的复杂性，而从4.0版本开始，实体框架引入了POCO数据模型，允许使用不从EntityObject继承的类。我们可能听说过这样一句话：POCO是不包含任何业务逻辑的、最底层的原始类，这句话表述不太准确，我们可以这样概括POCO的定义：POCO代表对域对象使用尽可能简单的类，可以包含属性、方法等，但是方法不能实现持久化逻辑，也就是说POCO也可以包含业务逻辑。使用Code First模型可以完全以面向对象的方式来工作，而不用担心数据库的结构，这种抽象使我们能够创建更加灵活的应用程序，让我们将重点放在关注应用程序的行为，而不是由其生成的数据库。其优点如下：● 这是最受欢迎的领域建模方式，可以允许我们创建一个更富有逻
辑、更灵活的应用程序。● 因为没有自动生成的代码是难以修改的，所以它提供了我们对代
码的完全控制。● 通过这种方法，我们只需要定义映射，其余一切交给Entity
Framework来处理，包括创建数据库表以及表之间的关系。● 这种方式可以通俗易懂地称为代码定义数据库，所以不推荐对数
据库手动更改。● 我们可以使用它来映射表结构到一个已存在的数据库。1.2.2 Model First
Model First允许我们使用实体设计器在空模型（扩展名为．edmx）中创建模型实体及其关系和继承层次结构，然后创建数据库，这种方法也被一些开发人员所使用。在Model First方法中，创建实体数据模型时必须选择“空模型”选项，而不是“从数据库生成”选项。其优缺点如下：● 如果你喜欢可视化应用程序中的数据结构或者不喜欢编写SQL，
那么它将会被你所喜欢，因为它会自动生成。● 在此方法中，我们无法控制实体和数据库，因为自动生成的代码
难以修改，所以这种建模方式已经越来越不被开发者所使用，但
是对于小型且简单的项目，它仍行之有效。● 要在POCO实体中添加额外的功能，我们不得不修改T4模板或者
使用部分类来完成。● 数据库模型的更改不是最佳选择，因为是由模型定义了数据库。1.2.3 Database First
Database First使我们能够从现有数据库（如SQL Server、Oracle、DB2等）创建模型，此方法减少了自动生成代码所需编写的代码量，同时也限制了我们使用生成代码的结构。其优缺点如下：● 如果我们已有DBA设计的数据来单独开发或现有已存在的数据
库，那么它将作为首选。● 通过EDM向导为我们创建实体、关系和继承层次结构，修改映
射后还可以生成POCO实体。● 要在POCO实体中添加额外的功能，必须通过T4修改模板或者使
用部分类。● 数据库的手动更改变为可能，因为数据库定义了领域模型，如果
要修改数据库表结构，只需要从数据库更新实体模型即可。1.3 使用Entity Framework Code First 6.x的原因
有些读者心生疑窦，为何不讲讲其他版本呢？因为EF 6.x之前的版本已经过时且性能极差，同时Entity Framework 6.x版本仍被官方所推荐使用。鉴于此，本书将从Entity Framework 6.x版本讲起，Entity Framework 6.x仍在更新且不断完善中，性能也在不断提高，所谓的性能不好很可能是我们没恰当使用而导致的，仔细阅读完整本书后，相信你会对Entity Framework重新认识。另外，有些人可能会反驳，认定Entity Framework就是个垃圾的存在，根本抵抗不了并发，请好好理解Entity Framework诞生的意义，Entity Framework的出现是为了让我们以面向对象的方式来梳理业务而不是抵抗并发，而Entity Framework作为底层数据访问，在大型项目中没有消息队列和缓存等机制，难道一切让Entity Framework来抵抗吗？1.4 小结
本章主要讲解了Entity Framework的发展历程以及对应的三种领域建模方式，并为接下来重点讲述Entity Framework 6.x和Entity Framework Core 2.0做铺垫。从第2章开始将正式进入主题，从基础讲起，同时会讲述每个版本的不同以及新特性。第2章数据库表的创建和迁移2.1 数据库连接和初始化策略2.1.1 数据库连接
下面将从最简单的例子入手，然后由浅入深，本书所有例子将用Fluent API演示，这样也方便维护。我们利用控制台进行演示，因为不是创建默认的应用程序，里面会包含Entity Framework程序集，所以在控制台中首先需要安装Entity Framework 6.0程序集，如图2-1所示。图2-1
接下来创建一个Blog类，代码如下：
然后创建一个继承自EF上下文的类，此上下文是与数据库交互的一个中间桥梁，我们可以称之为会话，并且为每一个模型公开一个DbSet，在上下文的派生类中定义DbSet有如下三种方式。● 用DbSet属性● 用IDbSet属性● 只读设置属性
最后在控制台的主函数中进行上下文实例化，并尝试添加Blog的实例，代码如下：
此时将看到连接到数据库出错（见图2-2），是未配置数据库实例而导致的，这种情况的出现是因为本地未安装LocalDB实例，那么我们怎么知道到底有没有安装LocalDB本地数据库呢？图2-2
运行命令SqlLocalDB.exe start v11.0，其中v11.0对应数据库版本，VS2013对应的本地数据库版本为v11.0，其余可以查看控制台中App.config或者Web.config配置的版本，VS2017对应的本地数据库如图2-3所示（其余对应版本请自行查看所安装的VS版本）。图2-3
若该命令不能正常使用，则说明本地数据库实例未安装；或者查看是否安装本地数据库实例，方式为：从VS工具栏中依次选择“视图”→“服务器资源管理器”→“数据连接”，右击添加连接，然后在呈现的界面中输入服务器名对应的数据库版本，比如（localdb）\v13.0，此时再点击测试连接，出现如图2-4所示的界面，也说明未安装本地LocalDB数据库实例。图2-4
在Entity Framework中配置的数据库连接默认为LocalDB本地数据库连接，但是我们可以手动通过EF上下文派生类的构造函数来配置数据库连接，如图2-5所示。其代码如下：图2-5
然后在配置文件App.config或者Web.config中配置数据库连接字符串，代码如下：
上面演示了用Entity Framework创建数据库表最简单的例子，到此关于连接数据库做一个总结：默认情况下，连接数据库生成的数据库名称为EF上下文所在的命名空间加上上下文名称，若手动配置数据连接字符串，则生成的数据库名称为我们配置的数据库名称。接下来介绍数据库初始化策略。2.1.2 数据库初始化策略
上述演示示例为数据库不存在的情况下，如果数据库已存在，Entity Framework是如何知道的呢？对此，我们能想到的EF团队早已明了，EF团队将此作为可配置的，所以在Entity Framework中初始化数据库有三种策略，需要在EF上下文派生类的构造函数中定义。● 如果数据库不存在，就创建：● 总是创建数据库，无论存在与否：● 如果EF检测到数据库模型发生了改变，将更新模型：
就实际情况而言，我们会设置数据库初始化策略为上述第三种，若已存在数据库，则当模型改变时，才重新创建数据库模型。
以上三种数据库初始化策略除了在DbContext派生类构造函数里面指定外，我们同样可以在配置文件中直接进行配置，例如：
在配置文件App.config或者Web.config中的AppSettings节点下进行配置：
上述key值DatabaseInitializerForType后面紧跟命名空间+DbConext派生类，其余两种初始化策略同理。如果想要禁用数据库初始化策略，那么在DbContext派生类和配置文件中该如何配置呢？代码如下：
或者2.2 约定
我们可以利用C#或者VB.NET语言借助Code First来描述模型，通过约定来描绘模型基础。所谓约定，类似于C#中的接口，它是一个规范或者规则，使用Code First基于类定义通过约定来配置概念模型并以此作为规则，约定是基本规则，我们可以使用Data Annotation或者Fluent API来进一步配置模型，这三者的优先级从高到低依次为Fluent API、Data Annotations、约定。下面我们来讲讲约定的几种形式。2.2.1 类型发现
当使用Code First时，我们首先需要利用.NET Framework来定义概念模型或者领域模型，类型定义完毕后，还需要让DbContext（EF上下文）知道到底包含哪些模型，所以此时需要进一步定义继承自DbContext的上下文派生类，然后通过DbSet作为属性来暴露模型的一部分，如果我们定义的模型有继承层次结构，那么只需要为基类定义一个DbSet属性即可，如果派生类与基类在同一个程序集，那么派生类将自动会被包含。其代码如下：
如果不想映射模型，那么可以通过Fluent API来忽略将其映射到数据库中，代码如下：2.2.2 主键约定
Code First根据模型中定义的ID（不区分大小写），或者是以类名加上ID的属性，推断这样的属性为主键，如果主键为int或者guid类型，那么主键将被映射成标识列（自增长）。如下DepartmentID将被映射成主键且自增长：
下面来看另一种情况，定义一个学生地址类（StudentAddress）：
接下来在DbContext上下文派生类中暴露StudentAddress模型（其余暂且忽略，后面会讲到），代码如下：
此时你觉得会发生什么呢？我们一起来看看，实例化上下文并获取是否通过，如图2-6所示。图2-6
此时显示错误的详细信息如下：
上述错误信息表明StudentAddress未定义主键，主键必须是ID（不区分大小写）或者类型加上ID，如上对模型StudentAddress的定义并未按照规制进行，所以要使类型定义验证通过，主键的定义必须是StudentAddressId或者ID，否则将抛出异常。2.2.3 关系约定
在Entity Framework实体框架中，导航属性成为连接两个模型关系的桥梁。为需要配置关系的模型定义导航属性，通过导航属性来管理两个或者多个模型之间的关系，此时Code First会根据模型定义来推断关系，除了定义导航属性外，我们推荐在有依赖对象的类型上定义外键属性，比如在一对多关系中需要定义外键属性，导航属性的定义遵循如下格式：
<导航属性名称><主体主键属性名称>或者<主体类名><主键属性名称>或者<主体主键属性名称>
若有多个匹配，则根据上述列举出的优先级进行外键属性映射，同样对于外键属性的检测不区分大小写，当推断出外键属性后，接着根据外键属性的可空性来推断关系的形式，如果外键属性为空，那么模型关系将配置为可选（即Code First不会在关系上配置级联删除），也就是说当主体被删除时，外键将被设置为null，否则会设置为级联删除。我们看看如下例子：
如果类型之间的关系比较复杂，此时只能利用Data Annotations或者Fluent API来进行手动配置。2.2.4 复杂类型约定
当Code First不能推断出一个模型中的主键且主键没有通过Data Annotations或者Fluent API来进行手动配置时，该类型将自动被配置
试读结束[说明：试读内容隐藏了图片]