O/R Mapping O/R Mapping的全稱是
Object Relational Mapping
主要目的是在傳統RDBMS與OO Language之間建映射關系
從而使開發人員徹底脫離數據持久這片剪不斷理還亂的苦海
關於O/R Mapping或者近來比較熱門的O/X Mapping（大家可以參考
程序員
P
）
可能需要專門的文章進行詳細論述
本文的目的主要是對現有方案的優缺點進行簡單剖析以及提供一些實踐中的參考信息
相比較J
EE平台
NET下的O/R Mapping可謂沒什麼歷史
至今還尚未有經過考驗的成熟的可用方案
但是
隨著各大廠商的重視以及開源項目的如火如荼
NET O/R Mapping的步伐也開始慢慢跟上
使這塊本屬於J
EE的領地加入了新的競爭對手（會不會使更多的開發人員投入
NET陣營？J）
也讓眾多疲於在SQL Clause或ADO
NET中來回奔命的DAL開發人員看到了
光明之路
接下來
就讓我們一起看看在這片比ADO
NET更廣闊的土地上有些什麼值得探討的Solution
Open Source 開源方面一直與
NET保持一定距離
O/R Mapping更是寥寥無幾
但就作者的下載試用和源碼分析來看
個人以為如下的兩個解決方案還是有一定參考價值的
OPF
OJB
有關這兩個開源項目的簡介
大家可以參考
程序員
P
OPF的全稱是
Object Persistent Framework
OJB的全稱是
ObJect Relational Bridge
在實現手法上
這兩個方案的思路完全不同
具有各自的代表性
OPF走的路線有點類似於Typed DataSet或Borland ECO（請參考下面的介紹）
實現比較簡單
提供更多的源碼級控制
而OJB的實現則類似於Microsoft ObjectSpaces（請參考下面的介紹）
采用了配置文件的方式
相對就比較復雜了
這兩個方案的基本框架如下所示
OPF 
從圖中不難看出
（
） Persistent類扮演了DataSet的角色
除了常規的對象數據操作外
還可以設定不同對象間的關系（如主從關系
集合關系等
這一點在Borland ECO所生成的代碼中也可略見一二）
這也是上文所說
提供更多源碼級控制
的原因所在
（
） PersistentSqlDataManager則扮演了DataAdapter的角色
通過預先設置的Commands來執行真正的數據庫操作
在實際撰寫的employee data manager中
開發人員確實需要提供基本的SQL語句
就像在SqlCommond中設置的那樣（Borland ECO則更進一步
以OCL代替了SQL）
（
） ObjectBroker的作用非常重要
它是對象與數據間的橋梁
RegisterPersistent方法建立了這種虛擬（Object）與現實（RDBMS）間的關系
（
） 在employee business object的聲明中
對象屬性與數據庫字段的對應關系是通過
NET Attribute機制體現的
所以修改起來還是比較方便的
雖然相比配置文件的方式顯得不夠靈活（請參考OJB的介紹）
比如
需要重新編譯
開發人員不得不關注數據庫字段等
OJB 從圖中不難看出
（
） 該方案的實現比較復雜
但用戶需要實際撰寫的代碼變少了（只需要編寫employee business object）
這其中的關鍵就在於引入了配置文件
同時
由於配置文件的引入
我們在hello world application中也不需要調用類似OPF解決方案（請參考上文的OPF類圖）中的RegisterObject方法
所有這一切（甚至包括數據庫連接信息）
系統都已了如指掌！
（
） 該方案中
SQL命令通過Criteria類被徹底替代
而QueryFacade則充當了Adapter的功能
通過PersistenceBroker這一真正的Command與數據庫進行通信
（
） 無論是repository
xml配置文件
還是Criteria
QueryFacade類
我們都可以在ObjectSpaces（請參考下面的介紹）中找到類似的實現（難道是巧合？）
同時
作者個人以為
這種方式也更符合O/R Mapping的精神
減輕了開發人員的負擔！
（
） OJB還有一個非常cool的工具
repositorygen
exe
可以用來生成repository
xml配置文件（同樣的
源碼無償奉上J）
這一點
甚至連ObjectSpaces都沒能做到（想想那麼多字段
屬性
關聯
映射
簡直可以讓人發瘋）！
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25578.html
