簡介
ADO.NET Entity Framework 以 Entity Data Model (EDM) 為主，將數據邏輯層切分為三塊，分別為 Conceptual Schema, Mapping Schema 與 Storage Schema 三層，其上還有 Entity Client，Object Context 以及 LINQ 可以使用。
ADO.NET Entity Framework 建模
Entity Framework 技術的套用中 ，可針對資料庫中各個表按照1:1 映射生成模型和映射信息 ，在代碼中直接對表中數據進行增、刪、改、查操作,但在實際套用中，這種簡單的處理方式不利於進一步降低程式開發工作量，部分情況還違背了“程式開發以套用為中心的概念模型來工作”的理念 ，對象的概念不清晰。為此 ，對幾種常用的資料庫情景的建模方法進行介紹 。
帶有有效載荷的多對多關係建模
在帶有有效栽花的多對多關係資料庫中 ，關係表除了主鍵外 ，還有其他數據欄位。在這種關係中 ，直接把表映射到實體模型中 ，兩實體表自動創建對應的實體類型 ，而關係表也被映射成為一實體類型 ，在此實體類型中除了原有屬性名 ，還有對應兩實體表的導航屬性 ，可分別通過 1 對多關係進行對象導航。
自引用關係建模
對於分類表之類的自引用表 ，把表映射成為實體類型後 ，其中將包含兩個導航屬性 分別對應父、子對象 ，其中父對象為 1 端 ，多端為子對象集合 ，因此分別把 1 端改名為父端名稱如Parent Category，多端改名為子對象集合名稱如 Sub Categories。由此兩導航屬性可方便地訪問到對應對象。
跨表實體建模
在資料庫設計過程中 ，當一個實體的數據由於各種原因為分割在不同表中 ，而程式開發需要把實體所有數據集合在一個實體類型中。對於這種跨表實體的情況 ，建模時首先把所有的表都映射到實體模型中 ，然後調整實體類型 ，把主要表之外的其它表映射實體類中除主鍵對應屬性外的所有屬性複製到主要表映射實體類型中 ，然後刪除主要表映射實體類型中的所有導航屬性和其它表實體類型 ，在刪除其它表實體類型時 ，不刪除映射存儲模型中
的表 ，最後 ，在剩下的這一個表映射實體類型中 ，添加複製得到的所有屬性的映射關係 ，分別映射到對應的表中的列。在實體操作過程中 ，映射關係能自動分別處理不同表中的對應數據。
多實體建模
在表中如果有部分欄位內容較多並且不常使用 ，為提高程式性能 ，訪問表時，一般只訪問表中的部分欄位， 為此 ，建模時必須把表分割成多個實體。首先把表映射成一般實體類型 ，然後在設計器中創建新實體類型 ，添加對應原表中主健的屬性 ，再把原映射實體類型中不需要的屬性通過“剪下 / 貼上”方法移動到新實體類型中 ，並把新實體類型中的所有屬性映射到原表對應欄位 ，然後在原實體類型中添加到新實體類型的 1對1（或 1 對 0.1）關聯關係 ，最後 ，在添加以新實體類型為主體的到原實體類型的引用約束。通過實體類型訪問數據時 ，兩實體類型對象分別訪問其屬性對應的欄位數據。
多表派生建模
資料庫建模完成後 ，對於有些表存儲另一表中額外信息的情況 ，可以針對這些表建立派生的類體系結構。首先,把所有表映射到實體模型中,分別映射成一個實體類型 ，然後刪除實體類型之間的關聯,再為基類（Business）添加繼承 ，分別設定派生類為Retails 和 e Commerces，再刪除派生類中的 Business Id 屬性 ，則根據表的結構完成類的體系結構建模 ，對 Retails 和 e Commerces 類型對象的操作會自動訪問庫表 Retails、e Commerces 及對應的 Business表中對應記錄。
表分割建模
對於常見的辦公自動化系統資料庫 ，由於員工類型不同 ，而薪水制度不同 ，其中 Employee Type 值為 1 則為臨時工 ，薪水按小時計算 ，Wage 欄位記錄其每小時薪水 ，Salary 欄位為無效 數 據 ，如 果 Employee Type 值 為 2 則 為 正 式 員 工 ，薪 水 按 月計算 ，Salary 欄位記錄其每月薪水 ，Wage 欄位數據無效。為更好地實現向套用編程 ，分別建立臨時工和正式員工兩種類型 ，但兩種類型的數據都保存在 Employees 表中。建模過程首先把 Employees 表映射到實體模型中 ，成為 Employees 類 ，然後添加新實體 Hourly Employee，指定基類為 Employees，然後通過“剪下 / 粘 貼 ” 把 Employees 中 的 Wage 屬 性 移 動 到 Hourly Employee中 ，用 同 樣 的 方法添加實體 Full Time Employee 類型;再在Hourly Employee 實體中 ，添加映射條件 ：“Employee Type = 1”，在Full Time Employee 實體中添加映射條件 ：“Employee Type = 2”，然後設定 Employees 類型為抽象類，並刪除其中的 Employee Type 屬性，則Hourly Employee和Full Time Employee自動處理 Employee Type 欄位的值 ，並能自動根據記錄創建對應類型的對象。
版本信息
ADO.NET Entity Framework自.NET 3.5以來就被集成於.NET中，最新版本是Entity Framework 6.1.3。
| 版本 | 支持.NET | 發布情況 | 備註 |
| Entity Framework 3.5 | 2.0+ | 包含於.NET 3.5中 | 支持EDMX生成，通過擴展可支持POCO類的生成 |
| Entity Framework 4.0 | 4.0+ | 包含於.NET 4.0中 | |
| Entity Framework 4.X | 4.0+ | 可通過NuGet獲取 | 支持Database First、Model First、Code First三種生 成模式 |
| Entity Framework 4.5 | 4.5+ | 集成於.NET 4.5中 | |
| Entity Framework 5.X | 4.5+ | 可通過NuGet獲取 | 支持枚舉欄位，性能有較大提升，支持.NET 4.0的版本 為Entity Framework 4.4 |
背景
ADO.NET Entity Framework 架構圖長久以來，程式設計師和資料庫總是保持著一種微妙的關係，在商用應用程式中，資料庫一定是不可或缺的元件，這讓程式設計師一定要為了連線與訪問資料庫而去學習 SQL 指令，因此在信息業中有很多人都在研究如何將程式設計模型和資料庫集成在一起，對象關係對應 (Object-Relational Mapping) 的技術就是由此而生，像Hibernate或NHibernate都是這個技術下的產物，而微軟雖然有了ADO.NET這 個數據訪問的利器，但卻沒有像NHibernate這樣的對象對應工具，因此微軟在.NET Framework 2.0發展時期，就提出了一個ObjectSpace的概念，ObjectSpace可以讓應用程式可以用完全對象化的方法連線與訪問資料庫，其技術概念 與NHibernate相當類似，然而ObjectSpace工程相當大，在.NET Framework 2.0完成時仍無法全部完成，因此微軟將ObjectSpace納入下一版本的.NET Framework中，並且再加上一個設計的工具(Designer)，構成了 ADO.NET Entity Framework。
Entity Framework 利用了抽象化數據結構的方式，將每個資料庫對象都轉換成應用程式對象 (entity)，而數據欄位都轉換為屬性 (property)，關係則轉換為結合屬性 (association)，讓資料庫的 E/R 模型完全的轉成對象模型，如此讓程式設計師能用最熟悉的程式語言來調用訪問。而在抽象化的結構之下，則是高度集成與對應結構的概念層、對應層和儲存層，以 及支持 Entity Framework 的數據提供者 (provider)，讓數據訪問的工作得以順利與完整的進行 。
(1) 概念層：負責向上的對象與屬性顯露與訪問。
(2) 對應層：將上方的概念層和底下的儲存層的數據結構對應在一起。
(3) 儲存層：依不同資料庫與數據結構，而顯露出實體的數據結構體，和 Provider 一起，負責實際對資料庫的訪問和 SQL 的產生。
架構
概念層結構
概念層結構定義了對象模型 (Object Model)，讓上層的應用程式碼可以如面向對象的方式般訪問數據，概念層結構是由 CSDL (Conceptual Schema Definition Language) 所撰寫。
一份概念層結構定義如下所示：
對應層結構
對應層結構負責將上層的概念層結構以及下層的儲存體結構中的成員結合在一起，以確認數據的來源與流向。對應層結構是由 MSL (Mapping Specification Language) 所撰寫2。
一份對應層結構定義如下所示：
儲存層結構
儲存層結構是負責與資料庫管理系統 (DBMS) 中的數據表做實體對應 (Physical Mapping)，讓數據可以輸入正確的數據來源中，或者由正確的數據來源取出。它是由 SSDL (Storage Schema Definition Language) 所撰寫3。
一份儲存層結構定義如下所示：
用戶端
當定義好 Entity Data Model 的 CS/MS/SS 之後，即可以利用 ADO.NET Entity Framework 的用戶端來訪問 EDM，EDM 中的數據提供者會向數據來源訪問數據，再傳回用戶端。
ADO.NET Entity Framework 有三種用戶端4：
Entity Client
Entity Client 是 ADO.NET Entity Framework 中的本地用戶端 (Native Client)，它的對象模型和 ADO.NET 的其他用戶端非常相似，一樣有 Connection, Command, DataReader 等對象，但最大的差異就是，它有自己的 SQL 指令 (Entity SQL)，可以用 SQL 的方式訪問 EDM，簡單的說，就是把 EDM 當成一個實體資料庫。
Object Context
由於 Entity Client 太過於制式，而且也不太符合 ORM 的精神，因此微軟在 Entity Client 的上層加上了一個供程式語言直接訪問的界面，它可以把 EDM 當成對象般的訪問，此界面即為 Object Context (Object Service)。
在 Object Context 中對 EDM 的任何動作，都會被自動轉換成 Entity SQL 送到 EDM 中執行。
LINQ to Entities
Object Context 將 EDM 的訪問改變為一種對對象集合的訪問方式，這也就讓 LINQ 有了發揮的空間，因此 LINQ to Entities 也就由此而生，簡單的說，就是利用 LINQ 來訪問 EDM，讓 LINQ 的功能可以在資料庫中發揮。
開發工具
ADO.NET Entity Framework 的開發，在 Visual Studio 2008 中有充份的支持，在安裝 Visual Studio 2008 Service Pack 1 後，檔案範本中即會出現 ADO.NET 實體數據模型 (ADO.NET Entity Data Model) 可讓開發人員利用 Entity Model Designer 來設計 EDM，EDM 亦可由記事本或文本編輯器所編輯 。
派生服務
主條目：ADO.NET Data Services
ADO.NET Entity Model Designer微軟特別針對了網路上各種不同的應用程式 (例如 AJAX, Silverlight, Mashup 應用程式) 開發了一個基於 ADO.NET Entity Framework 之上的服務，稱為 ADO.NET Data Services (項目代號為 Astoria)，並與 ADO.NET Entity Framework 一起包裝在 .NET Framework 3.5 Service Pack 1 中發表。
支持廠商
有數個資料庫廠商或元件開發商宣布要支持 ADO.NET Entity Framework:
(1) Core Lab，支持Oracle、MySQL、PostgreSQL 與 SQLite 資料庫。
(2) IBM，實現 DB2 使用的 LINQ Provider。
(3) MySQL，發展 MySQL Server 所用的 Provider。
(4) Npqsql，發展 PostgreSQL 所用的 Provider。
(5) OpenLink Software，發展支持多種資料庫所用的 Provider。
(6) Phoenix Software International，發展支持 SQLite 資料庫的 Provider。
(7) Sybase，將支持 Anywhere 資料庫。
(8) VistaDB Software，將支持 VistaDB 資料庫。
(9) DataDirect Technologies，發展支持多種資料庫所用的 Provider。
(10) Firebird，支持 Firebird 資料庫。
