ADO.NET實體框架經(jīng)過長時間的發(fā)展，很多用戶都很了解ADO.NET實體框架了，這里我發(fā)表一下個人理解，和大家討論討論。實體框架是 ADO.NET 中的一組支持開發(fā)面向數(shù)據(jù)的軟件應(yīng)用程序的技術(shù)。面向數(shù)據(jù)的應(yīng)用程序的架構(gòu)師和開發(fā)人員曾為實現(xiàn)兩個迥然不同的目標費盡心機。

他們必須為要解決的業(yè)務(wù)問題的實體、關(guān)系和邏輯構(gòu)建模型，還必須處理用于存儲和檢索數(shù)據(jù)的數(shù)據(jù)引擎。數(shù)據(jù)可能跨多個各有不同協(xié)議的存儲系統(tǒng)；甚至使用單個存儲系統(tǒng)的應(yīng)用程序也必須在存儲系統(tǒng)的要求與編寫高效且容易維護的應(yīng)用程序代碼之間取得平衡。

#T#實體框架使開發(fā)人員可以采用特定于域的對象和屬性（如客戶和客戶地址）的形式使用數(shù)據(jù)，而不必自己考慮存儲這些數(shù)據(jù)的基礎(chǔ)數(shù)據(jù)庫表和列。通過提升開發(fā)人員在處理數(shù)據(jù)時可以使用的抽象級別并減少創(chuàng)建和維護面向數(shù)據(jù)的應(yīng)用程序所需的代碼，可以實現(xiàn)這一目的。因為 實體框架 是 .NET Framework 的一個組件，所以 實體框架 應(yīng)用程序可以在安裝了 .NET Framework 3.5 Service Pack 1 (SP1) 的任何計算機上運行。

數(shù)據(jù)建模的一種由來已久且常見的設(shè)計模式是將數(shù)據(jù)模型分為三個部分：概念模型、邏輯模型和物理模型。概念模型定義要建模的系統(tǒng)中的實體和關(guān)系。關(guān)系數(shù)據(jù)庫的邏輯模型通過外鍵約束將實體和關(guān)系規(guī)范化到表中。物理模型通過指定分區(qū)和索引等存儲詳細信息實現(xiàn)特定數(shù)據(jù)引擎的功能。

物理模型由數(shù)據(jù)庫管理員進行優(yōu)化以改善性能，而編寫應(yīng)用程序代碼的程序員的工作主要限制為通過編寫 SQL 查詢和調(diào)用存儲過程來處理邏輯模型。概念模型通常用作捕獲和傳達應(yīng)用程序的要求的工具，常常以靜態(tài)關(guān)系圖的形式供項目早期階段查看和討論，隨后被棄用。許多開發(fā)團隊會跳過概念模型的創(chuàng)建，直接從指定關(guān)系數(shù)據(jù)庫中的表、列和鍵開始工作。

ADO.NET實體框架可使開發(fā)人員查詢概念模型中的實體和關(guān)系，同時依賴于 實體框架將這些操作轉(zhuǎn)換為特定于數(shù)據(jù)源的命令，從而為概念模型賦予生命。這使應(yīng)用程序不再對特定數(shù)據(jù)源具有硬編碼的依賴性。概念模型、存儲模型以及兩個模型之間的映射以外部規(guī)范（稱為 實體數(shù)據(jù)模型 (EDM)）表示?？梢愿鶕?jù)需要對存儲模型和映射進行更改，而不需要對概念模型、數(shù)據(jù)類或應(yīng)用程序代碼進行更改。存儲模型是特定于提供程序的，因此可以在各種數(shù)據(jù)源之間使用一致的概念模型。

EDM 由以下三種模型和具有相應(yīng)文件擴展名的映射文件進行定義。
◆概念架構(gòu)定義語言文件 (.csdl) -- 定義概念模型。
◆存儲架構(gòu)定義語言文件 (.ssdl) -- 定義存儲模型（又稱邏輯模型）。
◆映射規(guī)范語言文件 (.msl) -- 定義存儲模型與概念模型之間的映射。

ADO.NET實體框架 使用這些基于 XML 的模型和映射文件將對概念模型中的實體和關(guān)系的創(chuàng)建、讀取、更新和刪除操作轉(zhuǎn)換為數(shù)據(jù)源中的等效操作。EDM 甚至支持將概念模型中的實體映射到數(shù)據(jù)源中的存儲過程。有關(guān)更多信息，請參見 實體框架中的數(shù)據(jù)建模。

面向?qū)ο蟮木幊虒εc數(shù)據(jù)存儲系統(tǒng)的交互提出了一個難題。雖然類的組織通?？杀容^接近地反映出關(guān)系數(shù)據(jù)庫表的組織，但是擬合程度并不完美。多個規(guī)范化表通常對應(yīng)于單個類，類之間的關(guān)系并未按照表之間的關(guān)系一樣表示。例如，若要表示某個銷售訂單的客戶，一個 Order 類可使用包含對 Customer 類實例的引用的屬性，但是數(shù)據(jù)庫中的一個 Order 表行包含的一個外鍵列（或列集）具有對應(yīng)于 Customer 表中的主鍵值的值。一個 Customer 類可以具有名為 Orders 的屬性，該屬性包含 Order 類的實例的集合，但是數(shù)據(jù)庫中的 Customer 表不包含相應(yīng)的列。

現(xiàn)有解決方案只能通過將面向?qū)ο蟮念惡蛯傩杂成涞疥P(guān)系表和列來嘗試彌合這種通常稱為“阻抗不匹配”的差異。實體框架沒有采用這種傳統(tǒng)方法，而是將邏輯模型中的關(guān)系表、列和外鍵約束映射到概念模型中的實體和關(guān)系。這在定義對象和優(yōu)化邏輯模型方面都增加了靈活性。實體數(shù)據(jù)模型工具基于概念模型生成可擴展數(shù)據(jù)類。這些類是分部類，可以通過開發(fā)人員添加的其他成員進行擴展。為特定概念模型生成的類派生自一些基類，這些基類提供對象服務(wù)以將實體具體化為對象以及跟蹤和保存更改。開發(fā)人員可以使用這些生成的類以由導航屬性關(guān)聯(lián)起來的對象的形式來處理實體和關(guān)系。有關(guān)對象服務(wù)的更多信息，請參見對象服務(wù)概述（實體框架）。