簡述
在單個組件中封裝域對象和關系數據之間的映射。對象/關系映射同時把應用程序代碼和域對象從底層的數據模型和數據訪問細節中分離出來。
背景
程序員使用面向對象概念以自然的、熟悉的方式對現實世界中的實體建模。對象的行為使它能夠使用應用程序領域的語義與其他對象交互。通過聚合與繼承相連的域對象共同實現了優雅的應用程序級解決方案。
當需要讀寫域對象所表示的關系數據時，應用程序的簡潔性常常受到兵貴損害。這是因為直接使用關系數據對現實世界建模通常是不可能的。相反，現實世界的實體必須變形為行和列的格式。這種格式與面向這對象模型所提供的豐富性形成了鮮明的對比。
比如，考慮一個訂單處理應用程序中所涉及的一些對象。訂單包括惟一的訂單號、下訂單的客戶號、客房下訂單的日期以及組成訂單的0個或多個條目。類似的，一個條目由項目號、產品號、客戶訂購的數量和產品單價組成。圖1表示定義該用程序域對象的Order和LineItem類。
數據模型包括ORDERS和LINE_ITEMS表，它們定義了類似的概念，不過這些表之間的關系不是那么明顯，如圖2所示。因為一個訂單包含0個或多個條目，所以在ORDERS表和LINE_ITEMS表之間存在一對多的關系。為了建立表之間的聯系，LINE_ITEMS把ORDER_ID列定義為外鍵，可以使用它聯接ORDERS表。
我們來考慮應用程序必須執行的一個簡單的業務過程。生成訂單發票需要完成以下工作：
1.確定適當的查詢－－應用程序查詢ORDERS和LINE_ITEMSGE表搜集生成訂單發票所需要的全部信息。可能需要涉及兩個表的聯接操作，也可能要求每次涉及一個表的多次查詢。
2.發出查詢－－如果沒有可用的連接，應用程序初始化一個數據庫連接，并直接與數據庫驅動程序交互，發出查詢。
3.解析查詢結果－－應用程序讀取查詢結果中的數據，創建Order和LineItem對象表示這些數據。可能還涉及把數據從數據庫格式轉換成更符合應用程序語義的格式。
4.打印發票－－應用程序使用Order和LineItem遍歷所在的訂單，計算總價并打印發票。
第一步需要應用程序和數據模型緊密耦合，國為應用程序需要構造查詢。類似地，第二步和第三步耦合了應用程序和數據訪問代碼，在這里就是數據庫驅動程序及其資源。
對象/關系映射模式同時去掉了數據模型和數據訪問與應用程序及其域對象的耦合。面向對象的概念和關系數據之間的映射成為單個組件的職責，該組件可以獨立于應用程序和域對象修改。對象/關系映射通常使用對應程序隱藏其全部映射細節的抽象定義。圖3說明了對象/關系映射抽象和實現如何解除耦合：
對象/關系映射實現負責域對象和關系數據之間的映射，通常直接與物理數據庫驅動程序交互。一種方法是定義定制的實現，硬編碼域對象、應用程序或者系統的全部映射細節。在代碼中硬編碼細節不容易修改，但與把同樣的映射埋藏在應用程序代碼或域對象中相比，提供了更清晰的解耦。這種方法也可以作為一種有效的原型策略，在構造功能更完善的解決方案之前開發應用程序。
復雜的對象/關系映射系統使用元數據定義映射的細節。元數據使得實現實現非常通用，因為修改映射的細節不需要升級或重新編譯應用程序和域對象。通常映射元數據保存在配置文件或數據庫中。同樣普遍的做法是定義管理工具，使用戶無需要解持久元數據格式也能查看和更新映射細節。
對象/關系映射系統要解決的最基本的問題是，如何從面向對象的概念映射到關系數據庫的概念。表1描述了一種通用的類比。這些只是一般的原則，并不是必需的。可以為應用程序使用的每個表定義一個類。應用程序或者對象/關系映射為引用的每個行實例化一個對象實例。每個域對象都使用屬性公開類似的列值。
表1 面向對象和關系數據庫的一般類比
實際上并不總存在直接的對應關系。比如，對象/關系映射常常隱藏應用程序不需要的關系數據，如單純用于定義表關系的鍵或者標識屬性。此外對象/關系映射可以代表應用程序進行雙向數據轉換或者計算屬性，甚至封裝更多的數據模型細節。如果需要定義的域對象更遠地偏離這種類比，必須保證選擇的對象/關系映射系統支持要求的映射能力。
一旦定義了對象/關系映射，訂單處理程序中生成發票的步驟就很容易描述了：
1.請求訂單－－應用程序請求相關的訂單，對象/關系映射用Order對象集合返回訂單。
2.獲取訂單的每個條目－－可以直接在Order對象中取得。要記住在面向對象術語中，Order包含了LineItems集合，并且Order類把該集合作為一個屬性公開。
3.計算并報告－－像以前那樣計算總價并打印發票。
注意，應用程序完全使用域對象操作，沒有任何對關系數據模型或數據訪問的明確引用。發生的物理數據庫操作與前述耦合的方法相同，只不過這一次是由對象/關系映射幕后發出的。
解決像訂單處理應用程序所要求的這種簡單的情形，實現一個對象/關系映射是完全可以接受的。但是如果準備在應用程序中廣泛使用對象/關系映射，你可能不愿意接受這種挑戰－－從零開始創建一種通用的實現。編寫一個高效、通用、元數據驅動的對象/關系映射是一項困難的任務。所幸，有許多商業化的產品和標準可以直接在應用程序中使用。多數這類產品允許使用工具或配置文件定義映射元數據，為物理數據庫訪問插接不同的數據庫驅動程序。
適用性
對象/關系映射模式適用于以下情況：
需要向應用程序邏輯和域對象隱藏物理數據模型和數據訪問的復雜性。這樣做可以使這些成分更加整潔，集中處理所建模的業務對象和過程。
需要在單個組件中封裝域對象映射，以便能夠適應數據模型的變化而不必修改應用程序代碼或者域對象定義。
需要從域對象映射到多種數據模型而不修改應用程序代碼或域對象定義的通用性。這種通用使應用程序能夠與多種數據模型結合，不管它們是怎么定義的。
結構
圖4說明了一種對象/關系映射實現的靜態結構。PersistenceManager接口按照一般的域對象定義定義數據庫操作。它通常定義讀寫和刪除與對象的操作。這種接口不需要公開任何數據庫細節。也可以把持久性操作集合分散到多個接口，一起形成概念上的PersistenceManager抽象。
ConcretePersistenceManager依據物理數據庫操作提供了這些操作的實現。它引用某種形式的Map
data，后者描述了域對象映射。它也使用了PhysicalDatabaseDriver與關系數據庫交互。
ConcretePersistenceManager為應用程序封裝了數據模型、數據訪問和域對象映射。
在對象/關系映射標準和商業對象/關系映射系統中，存在這種結構的幾種變體。一種常見的變體是，通過隱式的框架和環境用從PersistenceManager中解耦應用程序代碼。其他的變體代替應用程序生成調用的映射代碼。
交互
圖5說明了應用程序對ConcretePersistenceManager調用讀操作時的情形。ConcretePersistenceManager找到描述映射細節的相關元數據，使用這些信息向物理數據庫驅動程序 發出操作指令。最后，它使用關系數據和元數據創建一個新的域對象并把這個對象返回給調用者。其他PersistenceManager操作的工作原理類似。
6.效果
對象/關系映射模式有如下效果：
權衡
依賴于另外的商品化產品－－多數應用程序都要使用一個商品化的數據庫、一個或多個數據庫驅動程序和一個應用程序服務器。如果大量地使用對象/關系映射，那么再集成一個商品化的對象/關系映射產品或許也是有利的。購買商品化產品可以顯著地降低開發成本。但是重新發布第三方軟件確實會帶來另外的法律、組裝和安裝的問題。
優點
清晰的應用程序代碼－－與包含數據模型和數據訪問細節的代碼相比，單純處理域對象的應用程序代碼更加清晰，也更容易開發和維護。如果使用定義良好的、只公開邏輯操作的域對象，應用程序的代碼就會更集中于它自身的業務邏輯。此外，當以后改變數據模型或數據訪問細節時也會處在更有利的位置。
映射到替換的數據模型－－最通用的對象/關系映射機制隔離了可配置的映射元數據，可以在不影響應用程序代碼的情況下修改元數據。許多對象/關系產品在運行時保存和解釋映射元數據，元數據的變化不需要重新編譯任何代碼。
映射到替換數據模型的概念具有很大的價值。通常數據模型都捆綁到應用程序上。這個特點嚴重地制約了數據模型的變更，國為需要廣泛地升級軟件。把數據模型細節封裝在元數據中允許改變數據模型，比如重新安排表、轉移不同的平臺，甚至轉移到像基于XML的數據庫或者面向對象數據庫這樣不同類型的數據存儲。
元數據也非常有益，可以很快使應用程序變化了的數據模型。從銷售和演示的角度看這一點尤其重要，因為可以快速配置應用程序使其處理預期客戶的遺留數據。當看到演示是在他們自己的數據環境下進行的時，潛在的客戶可能會更感興趣。
缺點
限制了應用程序對數據訪問的控制－－應用程序代碼只能訪問PersisenceManager接口定義的操作。因為ConcretePersistenceManager封裝了數據訪問的性能。如果采用商業對象/關系映射產品情況就更是如此。
7.策略
如果使用對象/關系映射機制管理域對象，合理的辦法是在整個應用程序中使用同樣的策略。對于從整體上理解和分析應用程序的數據庫交互，一致的數據訪問是有好處的。這一節討論實現對象/關系映射模式中可能遇到的各種問題。
非映射屬性
一般而言，參與對象/關系映射實例的域對象對應一個物理數據庫表或者聯接表中的一行。但是并不是域對象的所有屬性都需要保存在數據庫中。有時候，它們是根據其他來源計算或轉化而成的。這些屬性稱為非映射屬性，因為不是直接映射為關系數據的一部分。非映射屬性一般不會引起另外的映射問題，可以用域對象的映射屬性自動處理和計算。比如LineItem對象可能公開一個totalPrice非映射屬性，根據它的映射屬性unitPrice和quantity計算得到。