现在所有PersonalDetails的字段不再是Person的一部分。SalesPerson目前所做的在数据库里甚至是不可能的：它派生自Person，正如一个对象模型中的那样。
现在想象下你可以写一个类似这样的LINQ查询：
1 From p in People.OfType<SalesPerson> select p
与之而来的是你可以得到一些SalesPerson对象，所有的属性都定义在这个模型里面(参见图1-3)。
图1-3 SalesPerson对象
这点正是实体框架之所以能够把你从与数据库交互到如何把表格的数据转换成对象的痛苦之中解救出来的关键所在。
.NET仅仅只是使用EDM的一个工具。SQL Server的下一版本也会在报表服务里使用EDM，很快你将会看到微软其它的程序里也会采用EDM的概念。事实上，总的来说从微软那里你会发现模型驱动的开发方式正变得越来越受到关注。
当使用实体框架时，你将实现一个实体框架特定的EDM。在实体框架里，EDM在设计时由一个单独的XML文件来表示，然后在运行时会被分成3个XML文件，其中仅有一个用来表示概念模型。另外两个提供实体框架与数据库交换使用的元数据。你能在第二章中看到更多有关此元数据的内容。
实体:业务类的蓝图
EDM所描述的项称为实体。那些由模型实体以及他们的实例化对象产生的类也常被称作实体，但更长见的是把它们称谓实体类或实体对象。这些产生的实体类不同于经典的业务类的地方是，它们具有属性却没有行为除了有些开启跟踪修改的一些方法以为。
图1-4显示了Person与图1-2所展示的SalesPerson类的类图，这个类图会自动生成。每个类都有个工厂方法(例如CreatePerson)以及用来通知实体框架属性更改的方法。
使用实体框架产生的类，你可以添加你自己的业务逻辑，把结果放入你自己的业务对象，甚至把你的业务对象连接到该EDM，替换所产生的类。但是根据定义，这些实体类仅仅描述的是他们的模式。
除了能够像图1-2那样在数据模型里使用继承机制重构这些实体以外，你还可以定义实体间的关系。图1-5在模型里增加了一个Customer的实体，它也是派生自Person以及一个Order实体。注意SalesPerson和Order之间的关系连接线，显示它们间的一对多关系。在Customer与Order之间也有一对多的关系。
使用这个版本的模型进行查询时，你无须再使用JOIN连接了。该模型提供了实体间的导航。
下面的LINQ to Entity查询检索订单信息以及相关的客户资料。为了获取此Customer的FirstName和LastName，只需使用Order的Customer导航属性。
1 From o in context.Orders 2 3 Select new {o.OrderID,o.OrderNumber,o.Customer.FirstName,o.Customer.LastName}
一旦那些数据库在内存中，你就可以通过每个对象以及它们的属性来访问，比如myOrder.Customer.LastName,就那么简单。
有了实体框架，你可以检索图表，意味着你可以返回图形化的数据，比如一个Customer附带全部的Order详情。
这是一些查询数据模型而不是直接访问数据库的主要几点好处。
图1-4 Person与SalesPerson实体的类图
后端数据库:选择权在你
或许你也注意到了我并没有提及实际的数据存储，它们才是你所查询的数据的拥有者。模型对你的数据存储并没有太多了解：如数据库是什么类型的，而对于是什么模式就更知之甚少。其实它并不需要知道。
你所选择的后端数据库对你的模型和代码并不影响。
图1-5 SalesPerson和Customer实体，每个都与Order实体有关系
实体框架使用ADO.NET一直都在用的相同的ADO.NET数据提供程序,但是有点需要告诫。该提供程序必须做修改以便支持实体框架。提供程序参与重构了从实体框架查询与命令到本地查询与命令的部分。你所需要做的就是标明提供程序并提供到数据库的连接字符串，这样实体框架才能访问到数据库。
这意味着如果你需要写的程序针对一系列不同的数据库，你不必从头到脚的去学习每个数据库。你只需用实体框架的语法(LINQ to Entities或者实体SQL)书写查询，不必担心数据库之间的差异。如果你需要利用那些特定于数据库的功能与操作，实体SQL也能满足你那样做。
数据库提供程序
Visual Studio 2008 SP1与Visual Studio 2010里包含的微软的SqlClient API支持实体框架。它们允许你使用SQL Server2000,2005和2008.你可以使用SQL Server2005和2008的完整或体验版以及SQL Server 2000的完整版。这不是实体框架设计工具而是Visual Studio 2010本身的限制。没有Visual Studio的工具可以识别SQL Server 2000.但是，实体框架运行时可以。SQL Server CE 3.5和4版本也支持实体框架。查下地址http://blogs.msdn.com/sqlservercompact的2010年7月7日来自SQL Server CE团队有关SQL Server Compact 4的博客文章.
在写本章节时，有大量其它的提供程序可用了(很多也正在进展中),你可以使用Oracle,IBM数据库，SQL Anywhere,MySQL,SQLite,VistaDB以及很多其它数据库。这些提供程序由数据库厂商以及第三方厂商开发。大部分的这些提供程序都是为.NET3.5而写。只有一个关键特性它们不支持，直到升级到.NET 4:一个称为模型第一(model first)的特性，你将在第25章了解到。
注：微软在http://msdn.microsoft.com/en-us/data/dd363565.aspx的数据开发中心(DDC)的“ADO.NET数据提供程序”页上列出提供程序。
注：微软也为那些想要为他们的数据库提供程序构建实体框架支持的开发人员提供了指南。在本书中我未打算涉及这个话题。你可以访问http://blogs.msdn.com/b/adonet/archieve/tags/sample+provider浏览EF团队博客有关书写提供程序的文章。
Access与ODBC
支持实体框架的提供程序需要特别了解它所连接的数据库的类型。它需要了解这些数据有哪些可用的功能与运算操作，以及本地查询的特殊语法。开放数据库连接(ODBC)提供程序提供了对不同数据库的通用的访问，包括Access，但不能作为实体框架的提供程序而提供那些必要的数据库特性。因此ODBC不是一个有效的实体框架提供程序。除非有人专为Access创建一个提供程序，否则你无法在实体框架程序里使用Access。微软没有构建Access提供程序的计划，因为这要求太低了。
实体框架特性:API与工具
除了EDM以外，实体框架还提供了一系列的.NET运行时API使你能够使用EDM书写.NET应用程序。它也包含了一些设计模型的设计工具。下面是实体框架的关键特性的一个纲要。
元数据
尽管实体框架设计用来让你可以直接操作来自EDM的那些类，但还是需要与数据库交互。EDM描述的概念数据模型存储在一个XML文件里，它们的模型标识这些实体以及它们的属性。在EDM里描述概念模型后面的是另外2个XML文件，它们把你的数据模型映射到数据库。一个XML文件是描述你的数据库，另外一个提供了你的概念模型与数据库的映射。
在查询与更新命令执行时，实体框架需要搞清楚如何把由数据模型术语表达的查询或命令转换成你数据库术语表达的查询与命令。它就是通过这些元数据来实现的。
当数据从数据库返回时，它是用元数据来重构数据库的结果为实体并进一步实现这些结果的对象。
通过一个叫做code first的特性，实体框架可以使用内存中模型，这个特性属于实体框架社区技术预览版(CTP)的部分.它还不是实体框架的部分需要单独去下载。Code First允许你单独操作类，而那些必要的XML元数据是运行时在内存中产生的。你将会在第25章更多的了解这个特性，但是注意在本书出版时，code first还只是CTP，尚未开发完。
译注:由于本人水平有限，译后未做详细的审校，希望不会对您的理解造成误解或困惑。翻译选词时有过无数拿捏不定，举例说Model-First,大白话可能就是先从模型设计开始啦，想了很久还是从“模型第一”，“模型优先”，“模型在先"...最后干脆对这种新特性术语类还是直接原文吧"Model-First"，希望不会对您造成误解与不便，如果您对译文有什么建议或意见，欢迎指正，我会在审核后重新编辑，谢谢大家!