微軟的Entity Framework 受到越來越多人的關注和使用，Entity Framework7.0版本也即將發行。雖然已經開源，可遺憾的是，國內沒有關於它的書籍，更不用說好書了，可能是因為EF版本更新太快，沒人願意去花時間翻譯國外關於EF的書籍。使用Entity Framework開發已經有3年多了，但用得很膚淺，最近想深入學習，只好找來英文書《Entity Framework 6 Recipes》慢慢啃。首先需要說明的是，我英文不好，只是為了學習EF。把學習的過程寫成博客，一是督促自己，二是希望能幫助有需要的朋友。文中肯定有很多翻譯不當的地方，懇請你指正，以免誤導大家。謝謝！要說的就這麼多，下面就開始這一段學習過程吧。
處理關系數據庫時,我們依據由行和列組成的表，它高度結構化且擅長處理記錄集。在面向對象編程被廣泛接受之前,我們使用“procedurally（過程化）”的思維並通過編寫結構化的、自上而下的、一個一個的函數來解決問題。它們完美對應：在代碼中，表、行、列和結構化、過程化模式完美匹配。這樣的情況，持續了很長一段時間。
在編碼方面，我們現在使用面向對象和領域模型，架構、設計和編碼都對應於現實世界中的事情,比如客戶和訂單。我們在白板上寫出問題域（problem space)中的名詞，通過繪制它們之間的連線來表示關聯和交互。並以此作為規范和給開發團隊分配工作的依據。總之，架構、設計、和編碼是基於概念層，已經和關系型數據庫的組織和邏輯有很大的差別。
軟件開發中分析和解決問題的方法已經進化成熟，然而關系型數據庫卻沒有。很多年來，數據依然是保持在表、行、列這樣模式裡。不幸的是，它在面向對象繼承和高度標准化的關系型數據庫中產生了一個失配（阻抗失配，微軟件的安德斯.海爾斯伯格<C#之父>可能會這樣叫它）。
為了應對這一差距，項目中經常引入“數據庫層（database layer）”來轉換應用程序領域實體類中數據到表中的行和列進行保存。由此產生了許多商業和開發的數據庫訪問框架。他們都希望在進化式的開發和結構化數據中架起一座橋。有趣的是，一個新的解決方案-對象關系映射（ORM）產生了。
實體框架，以及集成查詢語言（LINQ)框架，他們均出自微軟，使我們能處理抗阻失配問題。使用實體框架，我們能在設計器或是代碼中直接對領域實體類進行建模。還能建立實體類之間的關系。面對這些實體類以及他們之間的關系我們構建LINQ查詢來應對，LINQ允許我們在代碼中使用實體類以及他們之間的關系來表達關系型數據庫中的概念。這些在幫助我們減少開發工作量的同時，還有助於簡化我們的開發體驗。相對大量、高度冗余代碼的ADO.NET數據訪問方式，我們使用LINQ查詢來表達我們對數據的需求。使用面向實體對象編程方式代替面向高度結構化的關系型數據庫開發方式，實體框架會幫你實現實體類到底層數據庫的映射。
注意：我們使用的術語實體類或實體對象，是一個代表應用程序中領域項的一個類。領域類代表現實世界中的對象，例如，你的項目中表示員工，部門，經理的類。 應用程序的最終用戶能夠在應用程序中看到領域類並說，“是的，這就是我們業務所做的”。實體類定義概要或者屬性，沒有行為，本質上，實體類暴露對象的狀態。
實體框架是微軟提供的實現應用程序訪問數據的戰略解決方案，不同以往的技術。實體框架與Visual Studio一起提供一個綜合的，基於模型的生態系統，它能讓你開發廣泛的面向數據的應用程序，包含桌面應用，互聯網應用，雲應用，以及基於服務的應用。本書將覆蓋絕大多數主題。
歷史
實體框架不是一個新事物，它可追溯到Visual Studio 2008 ，在功能和特性上它經歷一段漫長歷程。如圖1-1：
圖1-1 實體框架的簡短歷史
實體框架的第一個版本，提供了有限的功能，它只提供了ORM最基本的物性，只實現了一種叫做“數據庫優先（Database First）的方案，本書將對此方案時行充分展示。版本4.0帶來一種叫做“模型優先（Model First）“的方案，對簡單公共語言運行時對象（Plain Old CLR Object(POCO))的完整支持，以及默認的數據延遲加載行為。不久之後，實體框架的開發團隊發布了三個小的版本-4.1到4.3，提供了另一種叫體做“代碼優先（Code First）”的方案。如上圖所示，版本5.0隨.NET Framework4.5和Visual Studio2012一起發布。提供了重大的性能改進，並支持了枚舉類型，表值函數，空間數據類型，存儲過程的一系列改進，以及對asp.net MVC框架的深度支持。
現在實體框架已經到了版本6.0，提供了查詢和更新的異步支持，在代碼優先（Code First）中，存儲過程支持更新，性能改進，以及一系列的新特性，本書將聚焦這些新特性。
注意：實體框架版本5.0同樣也能在Visual Studio 2010中使用，版本6.0隨Visual Studio 2013一起發布，已提供對Visual Studio 2012 和Visual Studio 2010運行時支持。
對於分層集(level set），我們簡短地查看一下實體框架系統的關鍵組件。但絕不意味著是一個綜合的描述，它將用幾百頁的篇幅。我們通過查看一些關鍵點幫助你了解本書的核心。
模型
實體框架是一個強烈關注建模的技術，當你使用實體框架建模時，你會看到很多從之前的技術和模式繼承下來的似曾相識的符號。比如，一個相似的實體關系圖和廣泛采用的概念、邏輯、及物理分層方法。
實體框架創建的模型是一個名叫實體數據模型（EDM）的模型，它允許你在編碼時使用強類型的實體類，不是關系型數據庫中的結構和對象。（圖1-2展示了在概念層的模型），實體數據模型允許你自定義實體類和關系型數據庫表之間的映射，不僅僅是經典的一對一或類到表的映射。
圖1-2 實體數據模型
在圖1-2中，展示了左邊的數據庫表是如何不支持映射到右邊的代碼使用實體類型的。實體數據庫模型中的映射能力使用開發者可以使用與問題域（problem domain）高度一至的實體類型集，替代高度結構化的數據庫。以設計出高性能、可伸縮、可維護的代碼。
例如，上面圖中標注的，Employees,Devices,以及Phone Numbers 在物理存儲中是使用的三張不同的表。從DBA（數據庫管理員）的觀點來看，這是一個完美的場景。但是，從開發人員，或項目相關相關人員的角度來看，employee是一個單一的包含Devices和phone numbers的對象，開發人員編碼時使用一個單一的Employee實體類，它包含Devices和Phone Numbers的集合。開發人員不知道也不關心數據庫管理員是如何把這個對角分別存儲在三張不同的數據庫表中的。一旦配置，單一對象和三張數據庫之間的映射將被實體框架處理。
一個相反的情形是，上圖中的單表Department被映射成三個代表特定的departments。同樣的，開發人員和項目相關人員用一個單獨的對象來表示每一個部門（Accounting,Marketing,Finance,等等）,但DBA出於對數據在存儲的優化，將這三個對象整合到一個單一的數據庫表中。
當然，你能看到上圖中的Location表，你能很容易的將它映射到單一的實休類，也這是實體框架的默認行為。
這裡的關鍵點在，開發人員和項目相關人員使用表示應用程序上下文中的領域實體類，而DBA構建底層的數據庫表以求創建高效和數據庫。實體框架能很容易地架起兩者單的橋梁。
分層
實體數據模型包含3個獨立的層，概念層、存儲層、映射層。每個層互不耦合。
實體類包含在實體數據模型的概念層中，這一層為開發人員和項目相關人員所使用。根據你如何使用實體框架，概念層能通過設計器和代碼來建模。一旦做出決定，你可以使用逆向工程從一個已有的數據庫中建模，或借助設計器和大量的工具能通過代碼建模，以及使用實體框架來生成數據庫。概念層的語法是通過概念架構定義語言（CSDL）來定義的。
任何有用的應用程序都需要將對象持久化到某一數據存儲系統中，實體框架中的數據模型定義表、列，關系以及映射到底層數據庫中的數據類型。存儲架構定義語言（SSDL）定義了存儲模型的語法。
最後，映射層定義概念層和存儲層的之間的映射。除此之外，該層定義實體類的屬性如何映射到數據庫表中的列。它在實體數據模型的映射詳細信息窗口、數據注解、以及基於代碼方式的API向開發人員呈現。它的語法由映射規格語言（MSL)來定義。
術語
實體框架有自己的詞匯表，如果你已經使用別的流行的ORM工具或者與之相似的數據庫模型，也許，在這之前你已經遇到一些詞匯。雖然完整的詞匯表的數量是巨大的，但我們只提供少數基本術語便讓我們開始學習。
如前所述，一個實體類型代表領域模型中的一個類。一個實體類型的實例通常是指一個實體。如果你使用實體框架設計器，一個實體類型在設計器中被表示成一個擁有不同屬性的方框。圖1-3展示兩個實體類型：Employee和Task.
圖1-3 Employee和Task一對多關系的模型
一個實體類型一般擁有一個或多個屬性。像一個類，一個屬性是一個特定數據類型的指定值。 屬性可以是像 integer,string等簡單類型；也可以是復合類型（ComplexTypes）；或者是一個集合。導航屬性（Navigation properties）是指跟其它實體有關聯的屬性（數據庫中的外鍵關系）。在實體類型中不是導航屬性的屬性通常叫做標量屬性（scalar proerties）.
兩個實體之間的關系(relationship)叫做關聯(association). 實體類型間的關聯在設計器中表示為連接兩者的一條直線。線的兩端帶有表示多重性的注解。圖1-3中的關聯是一個表示Employeet和Task之間一對多的關聯。一個Employee可以有0個或是多個Tasks。每個Task關聯一個確定的Employee。
每個實體類型都有一個屬性或一個屬性集來指示它的實體鍵。在實體框架中一個實體鍵唯一標識一個實體，一般它被映射到實體對應的底層數據庫表的主鍵。
最後，沒有討論實體框架而不提到上下文對象（context object)的。上下文對象是實體框架服務的入口，它暴露實體對象，管理數據庫連接，生成參數化的SQL語句，從數據庫中封送（marshals）數據或封送數據到數據庫，緩存對象，維護對象變化跟蹤，把無類型的結果集轉換到一個強類型的集合對象。
一開始，上下文對象為ObjectContext對象，現在，實體框架支持另一個最新的名為DbContext的上下文對象。DbContext大大簡單化了使用實體框架的體驗。有趣的是，DbContext是ObjectContext的一個包裝器或者外觀實現者。以一種直觀的、友好的、有效的方式暴露底層ObjectContext的功能。
無疑，DbContext已經是使用實體框架的首先。同時本書也將非常詳細地介紹它。
代碼
盡管有可視化的設計器的強有力支持，實體框架到處是代碼，模型、實體類型、關聯、映射等最終的具體的代碼來表述，這些代碼最終成為應用程序的一部分。他們可以由Visual Studio和實體框架產生，也可由開發團隊手工創建。你可以選擇一些代碼生成工具來生成，或者通過修改你項目中不同的屬性，或者修改底層的代碼生成模板來生成。
Visual Studio 使用一個名為T4(Text Template Transformation Toolkit)模板的代碼生成技術來自動生成代碼。Visual Studio中的T4模板支持你編輯出能生成適合你確切需要的代碼的模板。雖然這是一項高級技術，但我們在很多情況下都需要使用它。我們將會向你展示如何修改它的一些方法。
作為一種選擇，你可以利用最新的代碼優先（Code-First）技術來手工創建具體的代碼，以此控制整個過程。使用代碼優先，開發人員可以在沒有設計器的幫助下創建實體類，映射，上下文對象。手工創建的實體類，一般是指簡單公共語言運行時對象（POCO-Plain Old CLR Objects），它沒有依賴實體框架設施。更有趣的是，開發團隊可以利用實體框架的強大的實用工具（可以從微軟官方網站下載）從一個存在的數據庫中逆向生成代碼優先模型。第八章將向你展示使用POCO創建之前的創建實體類、映射、上下文對象工作的基本過程。貫穿本書的大量方法將向你展示如何使用 Code-First 解決N-層架構的應用程序。
第一篇就暫時學到這裡吧，欲知詳情，請見下回分解。 如果你覺對你有幫助，請點右下解的推薦以示支持。謝謝。轉載請注明出處：http://www.cnblogs.com/VolcanoCloud/p/4475119.html
