微軟的Entity Framework 受到愈來愈多人的關注和使用,Entity Framework7.0版本也即將發行。雖然已經開源,可遺憾的是,國內沒有關於它的書籍,更不用說好書了,多是由於EF版本更新太快,沒人願意去花時間翻譯國外關於EF的書籍。使用Entity Framework開發已經有3年多了,但用得很膚淺,最近想深刻學習,只好找來英文書《Entity Framework 6 Recipes》第二版,慢慢啃。首先須要說明的是,我英文很差,只是爲了學習EF。把學習的過程寫成博客,一是督促本身,二是但願能幫助有須要的朋友。EF是微軟極力推薦的新一代數據庫訪問技術,它已經成熟,作爲一名.NET開發人員,若是你尚未使用它的話,那感緊開始吧,特別是DDD(領域驅動設計)的愛好者,更應該學習它,由於它是領域模型的絕佳搭檔!另外,本書也是一本關於EF的佳做(其實,英文的關於EF的書也就那麼幾本,中文的目前尚未,只有一些零星的資料,這會讓初學者會感受到混亂,特別是什麼EDMX文件、Code First、Model First、Database First、表拆分,實體拆分,TPT,TPH,TPC,CodeFirst和DDD的配合等等),就從本系列開始對EF進行一個系統的學習吧,老鳥也能夠從中瞭解很多的知識點。文中確定有不少翻譯不當的地方,懇請你指正,以避免誤導你們。謝謝!因爲書中的代碼只貼出核心部分,若是你想運行示例代碼,能夠加入QQ羣下載,由於太大,超過博客園的限制,因此這裏提供不了下載。要說的就這麼多,下面就開始這一段學習過程吧。html
處理關係數據庫時,咱們依據由行和列組成的表,它高度結構化且擅長處理記錄集。在面向對象編程被普遍接受以前,咱們使用「procedurally(過程化)」的思惟並經過編寫結構化的、自上而下的、一個一個的函數來解決問題。它們完美對應:在代碼中,表、行、列和結構化、過程化模式完美匹配。這樣的狀況,持續了很長一段時間。數據庫
在編碼方面,咱們如今使用面向對象和領域模型,架構、設計和編碼都對應於現實世界中的事情,好比客戶和訂單。咱們在白板上寫出問題域(problem space)中的名詞,經過繪製它們之間的連線來表示關聯和交互。並以此做爲規範和給開發團隊分配工做的依據。總之,架構、設計、和編碼是基於概念層,已經和關係型數據庫的組織和邏輯有很大的差異。編程
軟件開發中分析和解決問題的方法已經進化成熟,然而關係型數據庫卻沒有。不少年來,數據依然是保持在表、行、列這樣模式裏。不幸的是,它在面向對象繼承和高度標準化的關係型數據庫中產生了一個失配(阻抗失配,微軟的安德斯.海爾斯伯格<C#之父>可能會這樣叫它)。緩存
爲了應對這一差距,項目中常常引入「數據庫層(database layer)」來轉換應用程序領域實體類中數據到表中的行和列進行保存。由此產生了許多商業和開發的數據庫訪問框架。他們都但願在進化式的開發和結構化數據中架起一座橋。有趣的是,一個新的解決方案-對象關係映射(ORM)產生了。架構
實體框架,以及集成查詢語言(LINQ)框架,他們均出自微軟,使咱們能處理抗阻失配問題。使用實體框架,咱們能在設計器或是代碼中直接對領域實體類進行建模。還能創建實體類之間的關係。面對這些實體類以及他們之間的關係咱們構建LINQ查詢來應對,LINQ容許咱們在代碼中使用實體類以及他們之間的關係來表達關係型數據庫中的概念。這些在幫助咱們減小開發工做量的同時,還有助於簡化咱們的開發體驗。相對大量、高度冗餘代碼的ADO.NET數據訪問方式,咱們使用LINQ查詢來表達咱們對數據的需求。使用面向實體對象編程方式代替面向高度結構化的關係型數據庫開發方式,實體框架會幫你實現實體類到底層數據庫的映射。框架
注意:咱們使用的術語實體類或實體對象,是一個表明應用程序中領域項的一個類。領域類表明現實世界中的對象,例如,你的項目中表示員工,部門,經理的類。 應用程序的最終用戶可以在應用程序中看到領域類並說,「是的,這就是咱們業務所作的」。實體類定義概要或者屬性,沒有行爲,本質上,實體類暴露對象的狀態。asp.net
實體框架是微軟提供的實現應用程序訪問數據的戰略解決方案,不一樣以往的技術。實體框架與Visual Studio一塊兒提供一個綜合的,基於模型的生態系統,它能讓你開發普遍的面向數據的應用程序,包含桌面應用,互聯網應用,雲應用,以及基於服務的應用。本書將覆蓋絕大多數主題。dom
歷史異步
實體框架不是一個新事物,它可追溯到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
實體框架交流QQ羣: 458326058,歡迎有興趣的朋友加入一塊兒交流
謝謝你們的持續關注,個人博客地址:http://www.cnblogs.com/VolcanoCloud/