[實體框架編程]第一章 ADO.NET實體框架簡介(下)

接上篇

如今全部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詳情。

這是一些查詢數據模型而不是直接訪問數據庫的主要幾點好處。