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）中进化而来，这是在数据库开发中被用了好多年的概念。

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

实体数据模型（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同样也允许你存取图表数据，这意味着你可以返回特定形状的数据，例如携带订单细节的客户信息。

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