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

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

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

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

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

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

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

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

面向對象的編程對與數據存儲系統的交互提出了一個難題。雖然類的組織通常可比較接近地反映出關系數據庫表的組織，但是擬合程度并不完美。多個規范化表通常對應于單個類，類之間的關系并未按照表之間的關系一樣表示。例如，若要表示某個銷售訂單的客戶，一個 Order 類可使用包含對 Customer 類實例的引用的屬性，但是數據庫中的一個 Order 表行包含的一個外鍵列（或列集）具有對應于 Customer 表中的主鍵值的值。一個 Customer 類可以具有名為 Orders 的屬性，該屬性包含 Order 類的實例的集合，但是數據庫中的 Customer 表不包含相應的列。

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