接上篇

现在所有PersonalDetails的字段不再是Person的一部分。SalesPerson目前所做的在数据库里甚至是不可能的：它派生自Person，正如一个对象模型中的那样。

现在想象下你可以写一个类似这样的LINQ查询：

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导航属性。

From o in context.Orders

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

一旦那些数据库在内存中，你就可以通过每个对象以及它们的属性来访问，比如myOrder.Customer.LastName,就那么简单。

有了实体框架，你可以检索图表，意味着你可以返回图形化的数据，比如一个Customer附带全部的Order详情。

这是一些查询数据模型而不是直接访问数据库的主要几点好处。

 

 本文转自 xcf007 51CTO博客，原文链接：http://blog.51cto.com/xcf007/899442，如需转载请自行联系原作者