下载掌阅APP，畅读海量书库
立即打开
Entity Framework是一个Object/Relational（对象映射）Mapping实体框架，简称为ORM，可以在SQL Server、Oracle、DB2、MySQL等数据库上使用。我们可以将数据作为业务对象和实体来进行处理，开发者可以使用LINQ查询，然后使用C#面向对象语言来操作和检索数据。表1-1所示为Entity Framework的发展历程。
表1-1 Entity Framework的发展历程
一个业务领域由各个实体和各个相互关联且有各自的属性和行为的实体组成，每个实体都有其状态和验证规则需要维护，Entity Framework实体框架设计的出现就是为了允许开发人员着重关注业务领域，开发人员就实体来建模。它产生的目的是为了解决企业快速开发和迭代出市场所需要的系统或者软件。下面我们介绍Entity Framework中的三种领域建模方式。
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模型可以完全以面向对象的方式来工作，而不用担心数据库的结构，这种抽象使我们能够创建更加灵活的应用程序，让我们将重点放在关注应用程序的行为，而不是由其生成的数据库。其优点如下：
Model First允许我们使用实体设计器在空模型（扩展名为．edmx）中创建模型实体及其关系和继承层次结构，然后创建数据库，这种方法也被一些开发人员所使用。在Model First方法中，创建实体数据模型时必须选择“空模型”选项，而不是“从数据库生成”选项。其优缺点如下：
Database First使我们能够从现有数据库（如SQL Server、Oracle、DB2等）创建模型，此方法减少了自动生成代码所需编写的代码量，同时也限制了我们使用生成代码的结构。其优缺点如下：
有些读者心生疑窦，为何不讲讲其他版本呢？因为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来抵抗吗？
本章主要讲解了Entity Framework的发展历程以及对应的三种领域建模方式，并为接下来重点讲述Entity Framework 6.x和Entity Framework Core 2.0做铺垫。从第2章开始将正式进入主题，从基础讲起，同时会讲述每个版本的不同以及新特性。