概述

長久以來，程式設計師和資料庫總是保持著一種微妙的關係，在商用應用程式中，資料庫一定是不可或缺的元件，這讓程式設計師一定要為了連線與訪問資料庫而去學習 SQL 指令，至少對於我而言，我覺得這是一個很不爽的事情。因此在資訊業中有很多人都在研究如何將程式設計模型和資料庫整合在一起，物件關係對應 (Object-Relational Mapping) 的技術就是由此而生，像Hibernate或NHibernate都是這個技術下的產物，而微軟官方一直沒有推出類似的框架，依舊依靠ADO.NET這個傳統的資料訪問工具。估計微軟也聽到了來自程式設計師的抱怨，於是從一個ObjectSpace（ObjectSpace最早在2005年？被提出，可以讓應用程式可以用完全物件化的方法連線與訪問資料庫，其技術概念與NHibernate相當類似）的概念最後在2008年隨.net framework 3.5 SP1釋出了ADO.NET Entity Framework，一個附帶有圖形化設計器的面向實體資料庫訪問框架。

如圖：

NHibernate

NHibernate 是一個面向.NET 環境的物件/關係資料庫對映工具。物件關係對映(O/R Mapping，Object Relational Mapping)表示一種技術，用來把物件模型表示的物件對映到基於SQL 的關係模型資料結構中去。NHibernate是基於ms.net的O/R Mapping持久框架，它從基於Java的Hibernate專案移植而來。O/R Mapping就是把物件到對映關係資料庫的記錄，簡單的說就是能實現把一個物件儲存為資料表中的一條記錄和由一條記錄建立一個相應的物件，資料表中的資料就是物件的屬性。

NHibernate不僅僅管理.NET 類到資料庫表的對映（包括.NET 資料型別到SQL 資料型別的對映），還提供資料查詢和獲取資料的方法，大幅度減少我們開發時人工使用SQL和ADO.NET處理資料的時間。NHibernate的目標是對於開發者通常的資料持久化相關的程式設計任務，解放其中的95%。並請記住NHibernate作為資料庫訪問層，是與你的程式緊密整合的。

那麼為什麼要使用O/R Mapping？它與傳統的DataSet/DataTable又有什麼不同了？

首先是設計上的不同，當使用O/R Mapping時，更多的是從物件的角度來設計程式，而把資料(物件的屬性)儲存的細節放在後面, 可以完全採用面向物件(OO)的方式來設計，而在使用DataSet/DataTable時，它只是存放資料的物件，看起來更像一個數據表，不能直觀的表達業務概念。

NHibernate架構

NHibernate體系結構非常抽象的概覽

展示了NHibernate在資料庫和應用程式之間提供了一個持久層。

第一幅圖好像非常簡單？其實NHibernate是比較複雜的。我們瞭解兩種極端情況，輕量級和重量級架構。再來第二幅圖：輕量級體系，應用程式自己提供ADO.NET連線，並且自行管理事務。

最後一張圖：重量級體系：所有的底層ADO.NET API都被抽象了。

Hibernate優點：

（1）物件/關係資料庫對映(Basic O/R Mapping)

它使用時只需要操縱物件，使開發更物件化，拋棄了資料庫中心的思想，完全的面向物件思想。

（2）透明持久化(Persistent)

帶有持久化狀態的、具有業務功能的單執行緒物件，此物件生存期很短。這些物件可能是普通的JavaBeans/POJO，這個物件沒有實現第三方框架或者介面，唯一特殊的是他們正與（僅僅一個）Session相關聯。一旦這個Session被關閉，這些物件就會脫離持久化狀態，這樣就可被應用程式的任何層自由使用。（例如，用作跟表示層打交道的資料傳輸物件。）           

（3）事務Transaction (org.Hibernate.Transaction)

應用程式用來指定原子操作單元範圍的物件，它是單執行緒的，生命週期很短。它通過抽象將應用從底層具體的JDBC、JTA以及CORBA事務隔離開。某些情況下，一個Session之內可能包含多個Transaction物件。儘管是否使用該物件是可選的，但無論是使用底層的API還是使用Transaction物件，事務邊界的開啟與關閉是必不可少的。

（4）它沒有侵入性，即所謂的輕量級框架。

（5）移植性會很好。

（6）快取機制。提供一級快取和二級快取。

（7）簡潔的HQL程式設計。

Hibernate缺點：

（1）Hibernate在批量資料處理的時候是有弱勢。

（2）針對某一物件(單個物件)簡單的查\改\刪\增，不是批量修改、刪除，適合用Hibernate；而對於批量修改、刪除，不適合用Hibernate，這也是OR框架的弱點;要使用資料庫的特定優化機制的時候，不適合用Hibernate。

Entity Framework

在.Net Framework SP1微軟包含一個實體框架（Entity Framework），此框架可以理解成微軟的一個ORM產品。用於支援開發人員通過對概念性應用程式模型程式設計（而不是直接對關係儲存架構程式設計）來建立資料訪問應用程式。目標是降低面向資料的應用程式所需的程式碼量並減輕維護工作。

Entity Framework 應用程式有以下優點：

• 應用程式可以通過更加以應用程式為中心的概念性模型（包括具有繼承性、複雜成員和關係的型別）來工作。
• 應用程式不再對特定的資料引擎或儲存架構具有硬編碼依賴性。
• 可以在不更改應用程式程式碼的情況下更改概念性模型與特定於儲存的架構之間的對映。
• 開發人員可以使用可對映到各種儲存架構（可能在不同的資料庫管理系統中實現）的一致的應用程式物件模型。
• 多個概念性模型可以對映到同一個儲存架構。
• 語言整合查詢支援可為查詢提供針對概念性模型的編譯時語法驗證。

實體框架Entity Framework 是 ADO.NET 中的一組支援開發面向資料的軟體應用程式的技術。在EF中的實體資料模型（EDM）由以下三種模型和具有相應副檔名的對映檔案進行定義。

• 概念架構定義語言檔案 (.csdl) -- 定義概念模型。
• 儲存架構定義語言檔案 (.ssdl) -- 定義儲存模型（又稱邏輯模型）。
• 對映規範語言檔案 (.msl) -- 定義儲存模型與概念模型之間的對映。

實體框架 使用這些基於 XML 的模型和對映檔案將對概念模型中的實體和關係的建立、讀取、更新和刪除操作轉換為資料來源中的等效操作。EDM 甚至支援將概念模型中的實體對映到資料來源中的儲存過程。它提供以下方式用於查詢 EDM 並返回物件：

• LINQ to Entities -- 提供語言整合查詢 (LINQ) 支援用於查詢在概念模型中定義的實體型別。
• Entity SQL -- 與儲存無關的 SQL 方言，直接使用概念模型中的實體並支援諸如繼承和關係等 EDM 功能。
• 查詢生成器方法 --可以使用 LINQ 風格的查詢方法構造 Entity SQL 查詢。

下圖演示用於訪問資料的實體框架體系結構：

我認為的一些缺點：

·Edmx包含了所有物件的csdl，ssdl，msl檔案，過於龐大，如果要手動修改這個檔案，一不小心，眼睛看花了，就改錯了。（和資料集一樣的毛病）。

·目前EF支援表、試圖、儲存過程，其他的物件不支援，而且對使用儲存過程有很多限制（目前有EFExtension提供了更多物件的支援）。

·除了MS SQL Server可直接提供這種視覺化的設計介面外，其他的資料庫目前還沒有提供視覺化設計介面（但可以自己來實現，後面介紹）。

·效能問題。（網上看到有說比ADO.Net慢700百，又有人說比ADO.net快的，具體情況我還沒測試過, 但我覺得像這個些型別的框架，效能肯定是比上原生態的ADO.net慢）

案例：

Entity Framework 利用了抽象化資料結構的方式，將每個資料庫物件都轉換成應用程式物件 (entity)，而資料欄位都轉換為屬性 (property)，關係則轉換為結合屬性 (association)，讓資料庫的 E/R 模型完全的轉成物件模型，如此讓程式設計師能用最熟悉的程式語言來呼叫訪問。而在抽象化的結構之下，則是高度整合與對應結構的概念層、對應層和儲存層，以及支援 Entity Framework 的資料提供者 (provider)，讓資料訪問的工作得以順利與完整的進行。ADO.NET Entity Framework 以 Entity Data Model (EDM) 為主，將資料邏輯層切分為三塊，分別為 Conceptual Schema, Mapping Schema 與 Storage Schema 三層：
　　(1) 概念層：負責向上的物件與屬性顯露與訪問,讓上層的應用程式碼可以如面向物件的方式般訪問資料。這部分由設計器自動生成，表現在一系列的類。
　　(2) 對應層：將上方的概念層和底下的儲存層的資料結構對應在一起,負責將上層的概念層結構以及下層的儲存體結構中的成員結合在一起，以確認資料的來源與流向。這部分由描述語言實現，可以自由修改。
　　(3) 儲存層：依不同資料庫與資料結構，而顯露出實體的資料結構體，負責與資料庫管理系統 (DBMS) 中的資料表做實體對應 (Physical Mapping)，讓資料可以輸入正確的資料來源中，或者由正確的資料來源取出。 

對於訪問者（上層的邏輯）而言，可以使用三種方式訪問EDM：Entity Client，Object Context 以及LINQ 

1. Entity Client（資料庫操作訪問方式）

Entity Client是 ADO.NET Entity Framework 中的本地使用者端 (Native Client)，它的物件模型和 ADO.NET 的其他使用者端非常相似，一樣有 Connection, Command, DataReader 等物件，但最大的差異就是，它有自己的 SQL 指令 (Entity SQL)，可以用 SQL 的方式訪問 EDM，簡單的說，就是把 EDM 當成一個實體資料庫。 

2. Object Context（物件操作訪問方式） 

由於 Entity Client 太過於制式，而且也不太符合 ORM 的精神，因此微軟在 Entity Client 的上層加上了一個供程式語言直接訪問的介面，它可以把 EDM 當成物件般的訪問，此介面即為 Object Context (Object Service)，在 Object Context 中對 EDM 的任何動作，都會被自動轉換成 Entity SQL 送到 EDM 中執行。我個人比較傾向於使用這種方式。 

3. LINQ（LINQ操作的訪問方式） 

Object Context 將 EDM 的訪問改變為一種對物件集合的訪問方式，這也就讓 LINQ 有了發揮的空間，因此 LINQ to Entities 也就由此而生，簡單的說，就是利用 LINQ 來訪問 EDM，讓 LINQ 的功能可以在資料庫中發揮。