一、Entity Framework概要

Entity Framework是微軟的Object Relational Mapper(對象關系映射)，也就是我們平常說的ORM，它可以讓應用程序開發(fā)者將關系型數(shù)據(jù)作為業(yè)務模型來使用，也消除了開發(fā)者為數(shù)據(jù)訪問編寫的絕大多數(shù)管道代碼的需要（比如使用ADO.NET）。Entity Framework提供了一個綜合的、基于模型的系統(tǒng)，通過擺脫為所有的領域模型編寫相似的數(shù)據(jù)訪問代碼，使得開發(fā)者創(chuàng)建數(shù)據(jù)訪問層是如此之簡單。Entity Framework的首發(fā)版本是EF3.5，是伴隨著.NET Framework 3.5 SP1和VS 2008 SP1一同發(fā)布的。從那之后，EF已經進化了很多很多，當前版本是6.1.3。
Entity Framework通過開啟數(shù)據(jù)訪問和將數(shù)據(jù)表示為概念化模型（即一系列的實體類和關系），減輕了創(chuàng)建數(shù)據(jù)訪問層的任務。應用程序可以執(zhí)行基本的CRUD（CRUD是指在做計算處理時的增加(Create)、查詢(Retrieve)（重新得到數(shù)據(jù)）、更新(Update)和刪除(Delete)幾個單詞的首字母簡寫。主要被用在描述軟件系統(tǒng)中數(shù)據(jù)庫或者持久層的基本操作功能。）操作，以及輕松地管理實體間的一對一、一對多和多對多關系。

EF是微軟主推的數(shù)據(jù)存取技術，其他一些重要的微軟技術領域，比如ASP.NET MVC、WCF等，都使用EF構建數(shù)據(jù)存取層。在實際開發(fā)中，現(xiàn)在通常使用EF來構建應用程序的數(shù)據(jù)存取層。

二、使用Entity Framework的一些好處

因為開發(fā)者不需要為數(shù)據(jù)訪問編寫所有需要的ADO.NET管道代碼（所謂管道代碼即創(chuàng)建數(shù)據(jù)庫連接、打開數(shù)據(jù)庫、執(zhí)行查詢、返回數(shù)據(jù)、關閉數(shù)據(jù)庫），因此可以節(jié)省很多開發(fā)時間。
我們可以使用更高級的語言（例如C#）來編寫所有的數(shù)據(jù)訪問邏輯而不是編寫SQL查詢和存儲過程。
因為數(shù)據(jù)庫表沒有高級的關系（如繼承），然而實體是可以有的，所以業(yè)務模型（也就是概念模型）可以使用實體間的關系來適配應用領域。
底層的數(shù)據(jù)存儲可以相對輕松地被取代，因為所有的數(shù)據(jù)訪問邏輯都呈現(xiàn)在應用層而不是數(shù)據(jù)層。

• 開源，且有足夠的資源投入，持續(xù)完善。
• 可以訪問多種數(shù)據(jù)庫（如Oracle、DB2、MySQL等），但與SQL Server配合得最好。
• 更好地將應用程序與數(shù)據(jù)庫結構隔離開了。
• 足夠靈活：支持三種開發(fā)模式。

三、缺點

沒有原生編寫的SQL語句執(zhí)行速度快。

四、EF的系統(tǒng)架構與基本原理

從上圖中可以看出，EF在底層使用ADO.NET data provider，因此，它可以看成是對現(xiàn)有ADO.NET技術的一個“增強版”。
ADO.NET對數(shù)據(jù)庫存取引擎的封裝較少，因此，開發(fā)效率不如EF，但性能有保證。
EF提供了更高層的抽象，開發(fā)簡單，使用靈活，但性能比直接使用ADO.NET會有損失（因為它多了一個將LINQ查詢轉換為SQL命令的步驟）。

五、什么是ORM

幾乎所有的商業(yè)軟件都要存儲數(shù)據(jù)，多年來，Relational Database Management System（RDBMS）一直是開發(fā)者尋求的數(shù)據(jù)存儲。ORM是允許開發(fā)者使用面向對象的編程語言訪問RDBMS數(shù)據(jù)的一系列技術?？捎玫腞DBMS包括SQL Server, Oracle, DB2, MySQL等等。這些數(shù)據(jù)庫系統(tǒng)有一些共性。每個數(shù)據(jù)庫系統(tǒng)都支持一個或多個數(shù)據(jù)庫。數(shù)據(jù)庫都包含數(shù)據(jù)表，每個表都以表格的形式存儲數(shù)據(jù)，并且被分成了列和行。多個表中的數(shù)據(jù)行可能相互關聯(lián)。比如，一個訂單Order表中的Id可能存儲在一個流水表Transaction中。
過去，在像EF這樣的工具出現(xiàn)之前，開發(fā)者都是在軟件代碼內部嵌套的sql語句，這是因為編程語言不能原生理解Sql。比如，要從數(shù)據(jù)庫中檢索數(shù)據(jù)，然后將結果作為對象操作，必須使用ADO.NET要寫相當數(shù)量的代碼才行。具體來說，先定義一個存儲person的類，然后打開數(shù)據(jù)庫連接，創(chuàng)建具有查詢文本的命令，再執(zhí)行該命令的reader，然后對該reader的結果進行迭代，最后再使用來自reader的數(shù)據(jù)填充Person類的實例。你會看到，這里包含了很多步驟，而且更重要的是，這樣寫的代碼維護成本很高。比如，數(shù)據(jù)庫中改了一個列名，這樣還要去代碼中進行相應更改，否則運行時就會拋出異常。此外，我們數(shù)據(jù)庫中存儲的是標量值數(shù)據(jù)（int,string等），但我們的目標是一個對象或者對象圖。這樣看來，這種訪問數(shù)據(jù)的方式有很多問題。

首先，RDBMS的列類型和.Net類型之間有類型失配；其次，存儲和目標之間也不匹配，前者是標量值的集合，后者是具有屬性的對象。更糟糕的是，鍵入我們的person對象有一個更復雜的屬性List Phones，該屬性代表其他表的集合。這些問題在OOP和關系數(shù)據(jù)庫中被稱為“阻抗失配”（impedance mismatch）。
ORM這些工具出現(xiàn)的原因就是為了解決這種失配問題。ORM工具將存儲在數(shù)據(jù)表中的數(shù)據(jù)表示為對象，這比起傳統(tǒng)的代碼有很多優(yōu)勢：
它們使用原生.net類型暴露數(shù)據(jù)，使用簡單的屬性暴露相關的數(shù)據(jù)，提供編譯時檢查。
最后，在后面會看到，你會寫更少的代碼。更少的代碼意味著更少的bugs，不是嗎？：）

六、Entity Framework簡史

多年來，有許多ORM工具進入市場，有開源的，也有商業(yè)的。微軟也開發(fā)了自己的ORM工具。第一個是內置于.Net 3.5的LINQ to SQL。該ORM僅支持SQL Server和SQL Server Compact。2008年第一次發(fā)布的Entity Framework是第二次嘗試，相較于LINQ to SQL有很多優(yōu)點。首先，有自己的provider架構，因此對于所有的關系數(shù)據(jù)庫引擎都是開放的，而不僅僅是SQL Server。現(xiàn)在所有的主要RDBMS都有Entity Framework provider。
Entity Framework經歷了很多版本。
第一版只支持Database First。這意味著你要將設計器指向一個已存在的數(shù)據(jù)庫，然后就會生成一個包含數(shù)據(jù)庫和表抽象的代碼。除了代碼之外，還會創(chuàng)建一個EDMX文件，該XML文件包含了實體數(shù)據(jù)模型（因此你也就知道了EDMX的意思了Entity Data Model Xml）。它包括三個模型：邏輯，存儲和映射。邏輯模型（有時也叫概念模型）就是使用C#進行編碼的那個，存儲模型描述了數(shù)據(jù)是如何存儲到數(shù)據(jù)庫中的，映射模型提供了邏輯模型和存儲模型之間的映射。如果你在數(shù)據(jù)庫中更改了東西，那么你也要更新生成的模型，C#代碼也要再次生成。映射模型有一個基于ObjectContext的類，該類有數(shù)據(jù)庫中每張表的集合屬性，每個集合都是一個泛型集合，集合中的元素類型是從EF中的一個基類中繼承的。每個類都有屬性和相應的數(shù)據(jù)表中的列對應。
第二版，也就是EF4，也開始支持Model-First了。這樣 ，我們就可以使用設計面板創(chuàng)建實體類，然后設計器會產成SQL腳本來生成數(shù)據(jù)庫。對于這種方法，仍會生成EDMX文件，最終的結果是和Database First是相同的。
最后，EF的Code First在版本4.1中引入。Code First不需要EDMX文件了，每個實體也不需要從EF的基類中繼承了。這樣，代碼變得更加容易測試。這種方法也不需要依賴設計器了，你只需要編寫類就行，而且它們會自動地映射到數(shù)據(jù)庫中的表。當前的EF 6.1.3中的Code First已經相當強大了。

七、Entity Framework具有的潛力

EF對于微軟開發(fā)者可以做很多事情。
首先，它可以將數(shù)據(jù)庫暴露成對象的集合，這是通過利用很多關鍵的類完成的。前提是你要了解DbContext,這個類是EF Code First的核心，在高層次上是數(shù)據(jù)庫抽象。數(shù)據(jù)庫包含了表，每個表又包含了行和列。DbContext有泛型集合屬性，每個屬性的類型是DbSet<TRowType>對應于每個表。集合中的每個對象指的是一個實體，代表相應表中的一行。數(shù)據(jù)表中的列是定義在TRowType類中的屬性。一旦這個結構布局好了，那么你就能夠通過LINQ查詢來查詢底層的數(shù)據(jù)庫了。如果你將一個全新的TRowType類的實例添加到父集合中，然后使用DbContext API保存更改，那么這個新的對象就會變成相應表中的一行，該對象的每個屬性的值就會變成該行相應的列值。此外，EF有能力表示其他的數(shù)據(jù)庫工件，比如存儲過程和函數(shù)。數(shù)據(jù)庫結構的進化是很重要的一個問題，在大多數(shù)情況，隨著應用程序的變化，你需要添加列和表，EF是通過Migration（遷移）功能來解決這個問題的。這個能力允許你通過C#代碼更改數(shù)據(jù)庫結構，除了添加和刪除表和列之外，還可以添加索引。Migration可以沒有數(shù)據(jù)損失地進化數(shù)據(jù)庫模式。你將會看到，EF會暴露你需要使用C#訪問的一切數(shù)據(jù)而不需要編寫SQL，并且像對待你整個應用程序代碼的一部分來對待數(shù)據(jù)庫。你可以將migration代碼遷入到源代碼控制系統(tǒng)（Git/SVN）中，因為它也是C#代碼！

八、Entity Framework的架構

EF構建在provider架構之上。當開發(fā)者使用C#創(chuàng)建一個LINQ查詢時，EF框架引擎會連接一個provider，將它轉換成實際的SQL語句，最后發(fā)往數(shù)據(jù)庫。任何給定的provider都是連接Entity Framework和一個特定的RDBMS的橋梁。一旦該provider執(zhí)行了最終的SQL命令，結果就被EF物質化到.NET對象中。Data reader就是為了這個目的。理解EF構建于ADO.NET之上非常重要，因此，EF也使用了諸如connection，command，和data reader的概念。談到數(shù)據(jù)持久化，也就是插入，更新和刪除功能，插入時，開發(fā)者將一個實體類的實例添加到數(shù)據(jù)庫上下文中。相似地，之前添加到上下文中的實例被標記為changed或deleted，就會產生對數(shù)據(jù)庫即將執(zhí)行更新和刪除的語句。EF會檢查上下文中的每個對象，再次使用provider來創(chuàng)建RDBMS特定的insert,update,或delete命令。

九、Entity Framework建模和持久化

EF依賴概念模型完成工作，首先來理解一下什么是Entity Data Model（EDM）以及EF如何使用它管理數(shù)據(jù)庫操作。

理解EDM

概念數(shù)據(jù)模型是EF的核心。要使用EF,我們必須創(chuàng)建概念數(shù)據(jù)模型，即EDM。EDM定義了我們的概念模型類，這些類之間的關系，以及這些模型到數(shù)據(jù)庫模式之間的映射。
一旦創(chuàng)建了EDM,我們就可以對概念模型執(zhí)行所有的CRUD操作，EF會將所有的這些對象查詢翻譯成數(shù)據(jù)庫查詢（SQL）。一旦這些查詢執(zhí)行了，EF就會將返回的結果轉成概念模型對象實例。EF會使用存儲在EDM中的映射信息來執(zhí)行對象查詢到SQL查詢，以及相關的數(shù)據(jù)到概念模型的翻譯。
一旦EDM準備就緒，我們就可以使用模型對象來執(zhí)行CRUD操作。要能夠執(zhí)行CRUD操作，我們必須使用ObjectContext類。接下來讓我們理解一下這個類。

理解ObjectContext類

一旦我創(chuàng)建了EDM，我就有了應用程序中可以使用的所有的實體。然而，我還需要一個東西來讓我在這些實體上執(zhí)行各種操作。它就是EF中的ObjectContext類。
ObjectContext類是EF中的主要對象。它負責：

• 管理數(shù)據(jù)庫連接。
• 提供執(zhí)行CRUD操作的支持。
• 追蹤模型的更改，目的在于在數(shù)據(jù)庫中更新模型。

ObjectContext類可以理解成管理EDM中所有實體的東西，讓我們?yōu)檫@些實體執(zhí)行所有的數(shù)據(jù)庫操作。當我們想要保存一個新的或者更改的對象到數(shù)據(jù)庫時，我們必須調用ObjectContext類中的SaveChanges方法。
還有另一個類DbContext,它和ObjectContext類很相似。實際上，Dbcontext類就是ObjectContext類的封裝類。它是一個更新的API，而且它提供了更好的API來管理數(shù)據(jù)庫連接和執(zhí)行CRUD操作。因為DbContext是更好的API，所以我們會使用DbContext來執(zhí)行所有的數(shù)據(jù)庫操作。

十、Entity Framework的三種開發(fā)風格

• Database First:這是一種用于已存在數(shù)據(jù)庫模式的方法。使用這種方法，EDM是從數(shù)據(jù)庫模式中生成的，這種方法最適合于使用了已經存在的數(shù)據(jù)庫的應用。
• Code First:這種方法中，所有的領域模型都是以類的形式編寫的。這些類會建立我們的EDM，數(shù)據(jù)庫模式會從這些類中創(chuàng)建。這種方法最適合于那些高度以領域為中心并且領域模型類創(chuàng)建優(yōu)先的應用程序。這里需要的數(shù)據(jù)庫只是為了這些領域模型的持久化機制。
• Model First:這種方法和Code First方法很相似，但是這種情況下我們使用了EDM視覺設計器來設計我們的模型。數(shù)據(jù)庫模式和類將會通過這個概念模型生成。該模型將會給我們創(chuàng)建數(shù)據(jù)庫的SQL語句，然后我們可以使用它來創(chuàng)建數(shù)據(jù)庫并連接應用程序。

三種開發(fā)風格的比較：

Database First

主要的好處就是：如果數(shù)據(jù)庫已經存在了，那么只需要花一點時間就可以編寫數(shù)據(jù)訪問層。EDM可以從數(shù)據(jù)庫中生成，然后根據(jù)需求更改EDM。
一些場景：
對遺留的數(shù)據(jù)庫進行開發(fā)。
當其他團隊的DBA完成了數(shù)據(jù)庫設計時，一旦數(shù)據(jù)庫完成，應用開發(fā)就要開始。
當要開發(fā)數(shù)據(jù)為中心的應用時，應用領域模型就是數(shù)據(jù)庫本身，數(shù)據(jù)庫會頻繁修改來滿足新的需求。

Model First

和Database First相似，Model First最終以EDM結束。使用該EDM,我們可以創(chuàng)建概念模型和數(shù)據(jù)庫。使用這種方法的唯一原因就是我們真的想要使用視覺實體設計器。

Code First

Code First對于所有的業(yè)務邏輯以類實現(xiàn)，并且數(shù)據(jù)庫只用作這些模型的持久化機制時很有用。
選擇Code First的一些原因：
數(shù)據(jù)庫只是作為模型的持久化機制，即數(shù)據(jù)庫中沒有邏輯。
完全控制代碼，即沒有自動生成的模型和上下文代碼。
數(shù)據(jù)庫不會手動更改。模型類總是更改，然后數(shù)據(jù)庫基于模型類的更改而更改。

十一、如何選擇持久化方法

方法一：工作流決定樹

方法二：檢查清單

到此這篇關于Entity Framework系統(tǒng)架構與原理的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論