Programming Entity Framework 第二版 翻譯索引
后端數據庫：你來選擇
你可能注意到我還沒提及實際用於數據查詢的數據存儲。模型對於數據存儲一無所知，它是什么類型的數據庫，更不用說是什么構架。它也不需要知道這些。
你后端選擇的數據庫對於你的模型或者你的代碼沒有一點影響。
EF與ADO.NET已經使用的ADO.NET數據提供者溝通，但是有一個前提。提供者必須更新能支持EF。提供者在重新形成EF的查詢和命令到本地查詢和命令中參與。你所需要做的就是確定提供者和數據庫連接串，這樣EF能進入數據庫。
這意味着如果你想讓應用程序能工作於多個不同的數據庫，你不用學習每個數據庫的插入和讀取。你可以使用EF的語法寫查詢（LINQ to Entities或者Entity SQL），而不用擔心數據庫之間的差別。如果你想使用某個數據庫的函數或操作，Entity SQL允許你做同樣的事。
數據庫提供者
微軟包含在VS 2008 SP1和VS2010中的SqlClient APIs支持EF。它允許你使用SQL Server 2000, 2005和2008。你可以使用完整版或試用版的2005和2008，還有完整版的2000。注意實體數據模型設計器不能與Sql Server2000交互。這不是EF的設計限制，而是VS2010本身。VS的工具都不能識別SQL Server 2000。然而，EF運行時可以。SQL Server CE 3.5和4版本也都支持EF。查詢2010年7月7號SQL Server CE組發表的這篇關於SQL Server Compact 4的文章http://blogs.msdn.com/sqlser
Vercompact。
在這本書編寫的同時，其它的提供者也能獲得，更多的還在開發中，它們將允許你使用Orcale，IBM數據庫，SQL Anywhere, MySQL, SQLite, VistaDB及其它的數據庫。提供者由數據庫供應商及第三方供應商編寫。其中大部分基於.net 3.5編寫。有一個很重要的特性直到他們更新到.net 4才能支持，那就是模型優先（model first），這個你將在第25章學習到。
Access和ODBC
能支持EF的提供程序需要對它要連接的數據庫的類型有明確的認識。必須知道數據庫可用的函數和操作符，還有針對本地查詢的的正確語法。開放式數據庫連接提供程序為很多數據庫提供了通用的存取。其中包括Access數據庫，它不能為與EF的交互提供數據庫結節。因此，ODBC不是EF合法的提供程序。除非某人為Access創建明確的提供程序，否則你不能使用EF與之交互。微軟也沒有計划 為Access創建提供程序，因為了它的需求量太低。
實體框架（EF）特性：APIs和工具
除了EDM，EF提供了一系列.NET運行時APIs允許你使用EDM編寫.net應用程序。它也包括一系列設計模型的設計工具。下面是EF主要特性的概要。
元數據
雖然EF設計的是讓你直接到EDM的類工作，它仍然需要同數據庫交互。EDM描述的概念數據模型存儲在XML文件中，它的構架指定了實體及他們的屬性。在EDM的概念構架描述的背后是另一對XML文件，它映射數據模型到數據庫。一個是描述數據庫的XML文件，另一個提供了概念模型與數據庫間的映射。
在查詢和命令（例如更新）執行時，EF計算出如何將數據模型中的查詢或命令的表達轉化成數據庫的表達。它通過讀取元數據實現。
當數據從數據庫返回時，它使用元數據將數據庫結果轉成實體和更進一步的格式化對象。
EF通過代碼優先(code first)特性獲取使用內存模型的能力，它是EF社區技術預覽的一部分。它還不是EF的組成部分，必須分開下載。代碼優先允許你單獨與類工作，需要的XML構架在運行時飛速寫入內存。你將在第25章學習更多這個特性，但是請注意在這本書出版的時候代碼優先仍然是CTP，沒有完全開發出來。
實體數據模型設計工具
圖表1-2和1-3都是從EDM設計器中截圖出來的。它是VS的一部分，為用戶提供了可視化編輯模型的方式，而不用直接面對XML。在第2章中你將學習到正確使用設計器的方法，同時在第14章學到如何使用它做更高級的模型，例如繼承。第25章學習模型優先設計。你將了解到設計器的限制，例如它不支持EDM的所有特性。某些EDM不常用到的特性，你必須直接編輯XML文件。在第2 章，你將看到XML文件，及它如何如你在設計器中看到的相關連，這樣在第15章它改變時，你將對原生的構架文件有所熟悉。
在vs2010中，設計器比vs2008 sp1支持更多的特性。然后，在第14和15章中，你將看到仍然有一部分特性需要手工修改。
設計器也允許你映射存儲過程到實體中，這將在第6章中講到。如果你用過vs2008 sp1，你會發現在vs2010中設計器對於存儲過程的支持有很的改進和提高。
另一個值得一提的特性是它允許你從數據庫更新模型，添加你之前沒用到的數據庫對象或在模型之后添加到數據庫的對象。
數據庫優先設計
EDM設計器的一個工具是實體數據模型向導。它允許你指向現存的數據庫並從它直接生成模型，這樣你不用從頭開始。一旦你有了第一版的模型，你可以開始在設計器自定義模型了。
模型優先設計
並不是所有的開發都從現有的數據庫開始。Vs2010的一個新特性是直接在設計中創建模型然后基於該模型生成數據庫構架的能力。雖然在本書中我們關於使用數據庫優先設計創建模型，你還是有機會練習模型優先設計及一其它一些設計特性，在第25章中。
代碼生成
一旦你有了定義業務實體的模型，你就需要有在運行時代表它們的類。設計器能夠為了從模型自動生成這些類。然后，我們在vs2010中有另一個重要的特性。與在vs2008 sp1使用屬性代碼生成器不同，類全部由vs的文本模板轉化工具包(T4)生成。它不光為代碼生成提供了常用的機制，同時你可以更容易的自定義提供的模板以定義你想要從模型中生成的類。你將在第11章中學習代碼生成能力，然后在后面的章節中更深入的學習T4的自定義。某些場景下你可以跳過全部的代碼生成，僅使用你自己的類。
對象服務
EF在運行時最顯著的特性，也是你在工作時最常遇到的，就是對象服務。對象服務在EF堆的最上面，如圖1-6所示，它提供與基於實體的對象工作必要的功能。對象服務提供被稱為EntityObject的類，它很容易管理從EntityObject繼承的任何類。這包括為將查詢結果格式化為基於EDM的對象，跟蹤這些對象的變化，管理它們的關系及保存改變到數據庫。
在查詢和更新之間，對象服務提供了與實體對象交互的宿主主能力，例如與自動與低層的EF工作，為調用數據庫做必需的工作和處理結果。對象服務也提供了序列化（XML和庫）。
POCO支持
.NET 4最重要的運行時增加特性是EF管理不從EntityObject繼承的實體的能力。這是EF新的POCO（Plain Old CLR Objects）支持，你將在第13章學習到這個特性。POCO支持對於允許多樣的編輯風格非常重要。有了POCO實體，開發人員可以更空間的創建單元測試和持久化未知的實體類。這些能力對於遵循領域驅動和敏捷開發的代碼規范的開發人非常重要。這些同樣在.NET 3.5的EF中不可用。現在EF擁抱更廣闊的開發社區。
變化追蹤
一旦實體對象實體化，不管是做為從查詢中返回的結果還是在代碼中新創建的對象，對象服務能保持對該對象的追蹤。這個對於從查詢中返回的對象是默認的。當對象服務管理對象時，它保持對對象屬性或它與其它實體對象關系變化的追蹤。
對象服務然后在更新數據時使用變化追蹤信息。它通過比較實體的當前與原始值，構建每個對象（增加，修改或刪除的）的Insert, Update, Delete命令。如果你使用實體間的存儲過程，它將傳遞當前值（原始值特別地指定）給這些存儲過程。
關系管理及外鍵
關系是EDM危險的部分；然后在.net 4中，一個重要的新特性被加進來了：外鍵支持。在經典的實體關系模型中，外鍵在概念模型中沒有被暴露。EF在.NET 3.5 SP1中采用了這種范式。但是我們的開發人員由於多種原因仍然希望能存儲這些外鍵值。事實上，在本書的第一版中，我提供了一系列獲取和設置外鍵的辦法。現在EF在概念模型中支持外鍵。然后，為向后兼容缺乏外鍵這一特性，你仍然可以使用之前的機制將關系實例化為對象。
在本書中我將不會花太多時間關注采用舊的方式創建關系，因為它不是默認的，並且使用較少。如果你更深入的指導，如果在概念模型中缺乏外鍵時如何工作。我推薦你本書的第一版。
正如你將發現的，特別是在第19章，它就關系講的更為深入，即使有了外鍵，你也必須對關系如何工作有非常好的理解。一些與相關的數據工作的約定並不直觀，如果你打破這些規則，你可以寫代碼拋出異常或錯誤。第19章為EDM提供了深入理解，這樣你能以專家的方式同它工作。
數據綁定
你可以在很多數據綁定場景中使用實體。在Windows Forms和WPF，你可以使用實體作為數據綁定控件或綁定源控件的數據源，它在窗口中為對象和UI控件提供綁定。第9章提供一個很好示例，使用實體對綁定源控件進行編輯和更新數據。第26章關注從用戶界面中分離數據存取和其它業務邏輯層，以提供為應用程序提供更好的架構。
第9章也提供了WPF應用程序的實體數據綁定示例。VS2010介紹了WPF數據綁定的很多增加，當使用實體綁定數據時你將從中受益很多。
對於ASP.NET，有名叫EntityDataSource的數據源控件，它與ASP.NET的SqlDataSource和LinqDataSource控件類似，允許你申明綁定實體對象到界面上。第12章就是關於使用 EntityDataSource的。你將在那一章快速獲取使用ASP.NET 動態數據的綁定。
N層開發
EF為在.net 3下的N層開發做了重大的進步。在.net 3.5 SP1中，它太難了；同樣地，在本書的前一個版本，我花了很大篇幅致力於變通的做法。現在我們不僅能從外鍵中獲益，還能從狀態管理中得到回轉，它使用處理過得變得簡單。另外，POCOs使得N層開發更容易實現，這你將在本書的后續章節中看到。
對於分層應用程序，第24和25章專注於將數據存取任務從ASP.NET用戶界面中分開，你會看到WPF應用程序，ASP.NET Web Form應用程序，還有ASP.NET MVC應用程序，使用不同的模式分離邏輯。
實體客戶端
實體客戶端是EF中另一個主要的API，盡管你很少與它直接打交道。它為與數據庫的存儲過程和命令（與數據庫提供程序結合）工作提供必要的功能，執行命令，從過程中獲取結果，將它格式化為與EDM匹配的結果。
你可以直接與實體客戶端工作，或者與它頂端的對象服務工作。不光是因為它可以執行查詢，更因為它這樣是代表了對象服務。差別在於當你直接用實體客戶端時，你得到的是列表數據結果（雖然這些數據可以被轉化）。如果你用對象服務，它會把實體客戶端創建的數據轉化成對象。
由實體客戶端返回的列表數據是只讀的。實體客戶端非常合適報表和將數據從一個持久化轉移到另一個。只有對象服務提供變化追蹤及將變化保存回數據存儲的能力。
實體框架和WCF服務
你可以在能使用ADO.NET的任何地方使用EF，包括web服務和WCF服務。第17和18章中將帶你處理為EntityObject實體和POCO實體提供服務。
在這些章節中，我們也會看一下WCF數據服務，WCF RIA服務，被稱為自追蹤實體的特定的POCO模板，它對實體提供客戶端的變化追蹤能力，因此允許一種簡單的方式將變化發送給WCF服務，然后持久化它們到數據庫。
ADO.NET數據集和LINQ to SQL怎么樣？
EF只是ADO.NET堆最新的增加物。它是如何影響現有的使用DataSets和DataReaders或者LINQ to SQL的代碼的呢？你可以使用這些技術繼續寫新的代碼嗎？
DataSets
DataSet和DataReader不會消失。所有的現存的投資會繼續工作，你仍然可以使用這些技術存取數據並做交互。EF提供了一種完全不同的方式來存取數據。你不需要集成這兩種技術，例如，使用EF查詢一些數據，然后將它裝進DataSet；完全沒必要。你可以使用它們中任一個。正如你所了解的EF，你發現它提供了完全不同的方式存取數據。你可能發現EF適合某些項目，但是其它的，你可能仍然希望使用DataSets。
EF也以EntityDataReader的形式使用了DataReader，它也是同SqlDataReader一樣繼承自DbDataReader。它就是EntityClient查詢返回的東西。事實上，你會發現使用EntityClient查詢EDM的代碼看起來與你直接使用ADO.NET查詢數據庫的代碼非常相似。它使用連接，命令，命令參數，返回DbDataReader，你可以使用任何你能使用的DataReader，例如SqlDataReader，從它那讀取數據。
在Ef中不可用的一些ADO.NET工具是查詢通知和 ASP.NET SqlCacheDependency。另外，ADO.NET SqlBulkCOpy需要DataReader或者DataSet將數據以流的形式存入數據庫。EF沒有與ADO.NET DataAdapter.BatchUpdate相對等的東西，因此，當EF保存變化到數據庫時，它一次只能發送一個命令。
LINQ to SQL
LINQ to SQL和EF在表面看起來很相似。他們都使用數據模型提供了基於數據庫的LINQ查詢。
一個常被問到的問題是：為什么微軟創建兩個相似的技術？LINQ to SQL從LINQ工程中進化而來，它來自於語言開發組。EF是數據編程組的工程，它關注於實體SQL語言。等到這兩種技術成熟時它在微軟向其它組展示，很明顯微軟有兩個非常棒的技術，它們可以應用於不同的場景中。EF組使用LINQ與實體工作，它讓開發更加困擾因為LINQ to Entities和LINQ to SQL看起來很像。
LINQ to SQL 最終引入到微軟的數據程序組，2008年11月該組發表了申明因為技術解決同一樣的問題，他們會專注於開發EF，支持多樣數據庫並且與微軟即將使用實體數據模型的技術看齊。然而，他們會繼續維護增強LINQ to SQL。這對於使用LINQ to SQL的開發人員不是一個樂觀的形勢。微軟承諾維護ADO.NET中的LINQ to SQL，並沒有發表申明放棄它。它也承諾會提供LINQ to SQL到EF的遷移，並推薦在未來的開發當中使用EF替代LINQ to SQL。
實體框架（EF）的痛處正在消失
在本書的第一版中，第1章列出了兩頁痛苦的地方。當時的標題是"EF設計器"（它關注於缺少對存儲過程及其它EDM特性的支持），"分布式應用程序變化追蹤的挑戰"，"領域驅動開發"和"單元測試"。感謝.NET 4和vs2010的改進，我很高興移除了這些章節。
然而，還是大量無用的地方需要關注。模型會從例如支持唯一的外鍵，表格值功能，增強的多對多關系中獲益，一個最主要的問題是：對於大模型的支持。
EF的狀態管理和關系管理仍然還有許多不直觀的行為，如果你不仔細研究，它很有可能咬你一口。請查看第19章獲取一個不錯的研究指導。
本書花費了大量時間深入研究了EF的運行時，向你展示一些限制，嘗試指出一些不平坦及遺漏的地方。
更成熟的ORM工具用戶繼續對EF提供抱怨，例如提供內部交互的難處（數據庫轉移，然后是支持的）。但是如果你縱觀市場，甚至是EF最強烈的競爭對手都開始提供與EF工作的高級工具。最主要的對手，Nhibernate，為EF創建了非常完美的數據庫設計，LLBL Gen Pro已經為EF創建了強大的設計器，它為管理EFEDM和它的元數據提供了不同的方法。
使用EF編程
當你通覽本書時，你會獲得設計EDM和使用EF編寫應用程序的經驗，還有深入理解API，學習如何操作實體對象及基於它們行為的一般性控制。很多功能都是可理解的，也有很多隱藏的能力。你將學習到背后有什么，這樣你會意識到EF真實的益處。
甚至在我全神貫注於這個版本的Programming Entity Framework，我期待框架的未來版本，因為它是在持續演化的。