[Programming Entity Framework] 第1章 ADO.NET实体框架介绍（一）

 

Programming Entity Framework 第二版 翻译索引

 

在微软2009年开发者大会上，微软非常著名的工程师说，"如果你是.NET开发人员，EF是我们的目标。我们在那儿，来吧，时机到了。"。

是的，时机到了。

在此之前，开发人员花费了太多时间担心他们后端的数据库、表及他们的关系、存储过程的名称及参数、视图还有他们返回数据的模式。对于.NET开发人员，微软新的EF改变了游戏规则，这样他们在编写应用程序时不必再关注于数据存储的细节。你可以关注编写这些应用程序的任务，而不是访问数据。

ADO.NET 实体框架已经变成了微软创建.NET应用程序核心的数据访问平台。它是在2008年7月，也就是2006年开发者大会宣布它的两年后，作为VS2008 SP1和.NET 3.5 SP1的一部分发布的。作为第一版的产品，EF受到了怀疑，它也未得到大部分人的接受。然而，随着在2010年4月vs2010和.NET 4的发布，得到很大改善的EF最终获得了很多开发人员和.NET小组的关注和热烈的反响，这些人也很快使用上了它。

虽然ADO.NET保持了它现有的数据访问，随着微软核心的数据存储策的进步，EF将从业务平台部门（它们拥有微软所有的数据编程任务）获得大部分的更新和资源。对于微软这是一个非常重要的技术，也是你不容忽视的。EF也集成到了微软的很多产品中，不论它们使用EF以支持它自身的特性，如Commerce Server 2009的 Multi-Channel Commerce Foundation，还是产品支持与EF的集成，如SQl Server建模。

为什么我们需要新的数据存储技术呢？在强制让开发人员从一种数据存储技术切换到另一个之后，例如，从DAO到RDO到ADL，然后到ADO.NET，在ADO.NET中微软终于扎根于一个开发人员能投资的产品中。每一次VS和.NET框架版本的发布，ADO.NET一直被增强和引入，但仍然一直保持向后兼容。我们的投资一直是安全的。

它还是安全的，虽然它将停滞。EF是ADO.NET的另一个增强，它给予开发人员一个除了DataReader和DataSet之外的新的访问数据及与结果工作的机制。

但是微软一直保持DataSet机制。下一步是允许开发人员关注于领域模型，而.NET能自动处理数据库交互的复杂任务。

在本章中，你将了解到EF关键的部分，实体数据模型，实体类，.NET APIs的核心，VS设计工具。你也会了解到EF如何适应ADO.NET 的DataSet和LINQ to SQL。最后，你将学习到关于EF在VS2010和.NET 4中的改进，及为何第一版本中的很多痛处都被消除了。

 

实体关系模型：对模型编程，而不是数据库

EF的核心好处是将你从关注数据库结构中解放出来。所有的数据读取和存储都通过反映业务对象的概念数据模型完成。

使用ADO.NET DataReader和其它数据读写技术，你在编写代码从数据库获取数据、读结果及挑选需要的数据并将他们放入业务类上花费了太多时间。而通过EF，你不再面对数据库的模式查询，而是面对反应业务模型的模式。当数据取到时，你不再被强制从行和列中读取数据并把它们塞进对象中，因为他们返回的就是对象本身。当保存变化到数据库时，你也仅需要保存这些对象。EF为将对象转化回行和列的关系存储做了必要的工作。EF与对象关系映射(ORM)工具相类似，为你做了这方面的部分工作。

EF使用一种被称为实体数据模型(EDM)的模型，它从实体关系模型（ERM）中进化而来，这是在数据库开发中被用了好多年的概念。

实体数据模型的根源

微软的EF从以ERM的理论中进化而来，它在白板中被用了30多年。ERM定义了实体的架构及它们彼此的关系。实体与对象不一样。实体定义了对象的架构，但不是它的行为。所以，实体看起来像数据库中表的架构，而不是业务对象的架构。开发人员画了好多年的ERM，以帮助我们如何将数据库中结构化的列表数据转化成我们能直接编程的业务对象。

提到ERM就不得不说一下Dr. Peter Chen，它在ERM的定义中提到"实体关系模型-即将到来的统一的数据视图"。

在拥有数据库领袖的队伍中，微软的研究开始设计一种能自动处理概念模型与数据库构架的中间桥梁。它必须是双向的，这样开发人员能从数据库获取数据，填充实体，并将它们持久化回数据库中。

在2006年6月，微软研究院发表了EDM的第一个论文，它回答了ERM。这份论文的作者包括数据库领袖Jim Gray，不幸的是他在2007从旧金山海湾起航后消失了。

 

实体数据模型：客户端的数据模型

实体数据模型（EDM）是客户端的数据模型，它是EF的核心。它与数据库模型不同，数据库模型属于数据库。应用程序中的数据模型描述了业务对象的结构。就好像你给了它权限去重构企业数据库中的数据表和视图，这样表和关系看起来更像业务领域，而不是由数据库管理员设计的一般架构。

图1-1展示了数据库中典型的表集合的架构。PersonalDetails提供了Person附加的信息，数据库管理员为了可扩展，选择将它放在了分离的表中。SalesPerson表用于为销售人员提供附加的信息。

使用T-SQL查询获取SalesPerson记录集连同Person具体信息的语句应用看起来像这样：

SELECT    SalesPerson.*, PersonalDetails.*, Person.*

From     Person

       INNER JOIN PersonalDetails

       ON Person.PersonID = PersonalDetails.PersonID

         INNER JOIN SalesPerson ON Person.PersonID = SalesPerson.PersonID

设想某个特定的应用程序可能有它自己的希望视图，它也是数据库看起来像的视图。图1-2改造了架构。

PersonalDetails的字段现在全部都是Person的一部分。而SalesPerson做的事情甚至在数据库都是不可能的：它从Person继承，就像你在对象模型中做的那样。

现在设想你能写这样的LINQ查询：

From p in People.OfType<SalesPerson> select p

在返回中，你得到SalesPerson对象的集合，它拥有这个模型定义的全部属性（参见图1-3）

注：LINQ只在C#和VB语言中存在。在EF中有另外一种表达查询的方式，它不但允许你使用别的语言，而且提供了附加的好处，你可以尽可能的利用它。它就是Entity SQL，在第3章到第5章中你将了解到更多关于它和LINQ to Entities的内容。

这就是EF能移除痛处的关键所在，它不光能与数据库交互，同时可以将列表数据转化成对象。

.NET不是第一个使用EDM的。下个版本的SQL Server将为报表服务使用EDM， 很快你也将看微软其它的产品将会采用EDM的概念。事实上，你将发现微软正越来越关注模型驱动开发。

当使用EF时，你将实现EF独有的EDM。在EF中，EDM在设计阶段由单个XML文件表示，它在运行时被分割成三个XML文件的集合，只有一个代表着概念模型。其它两个提供EF与数据库交互的元数据。你将在第2章中学到更多关于元数据的内容。

 

实体：业务类的模板

由EDM描述的项被称为实体(entities)。由模型实体生成的类，连同它的实例化对象，在被提及时都是指实体，但是更多时候它被称为实体类或实体对象。被生成的实体类与典型的业务类有差别，业务类有属性而没有除了允许变化追踪方法外的行为。

图1-4展示的Person和SalesPerson类的类图，在图1-2中会自动生成。每个类有一个工厂方法（例如：CreatePerson），还有当属性改变时用于通知EF的方法。

使用EF生成的类，你可以添加自己的业务逻辑，将结果放入自己的业务对象中，甚至将你的业务对象和EDM链接起来，取代生成的类。但是借助于定义，实体类仅描述他们的架构。

为了能够重构像图1-2中展示的继承关系的数据模型中的实体，你可以定义实体间的关系。图1-5添加了Customer实体到框架中，它也是从Person类继承，同样Order实体也是。注意SalesPerson和Order之间的关系线，展示了他们之间一对多的关系。在Customer和Order之间也有着一对多的关系。

当针对这个版本的框架写查询时，不用使用JOINs。模型提供了实体间的导航。

下面的LINQ to Entities查询返回Order信息，连同Customer。它导航到Order的Customer属性以获取Customer的Firstname和LastName。

From o in context.Orders

Select new {o.OrderId, o.OrderNumber, o.Customer.FirstName, o.Customer.LastName}

一旦数据存储在了内存中，你可以通过每个对象及它的属性来访问它，例如：myOrder.Customer.LastName，就是这样简单。

EF同样也允许你存取图表数据，这意味着你可以返回特定形状的数据，例如携带订单细节的客户信息。

基于数据模型查询相比直接从数据库查询有一些主要的益处。