剖析 .Net 下的數據訪問層技術（三）
2024-07-10 13:03:38
供稿：網友
u o/r mapping
o/r mapping的全稱是：object relational mapping，主要目的是在傳統rdbms與oo language之間建映射關系，從而使開發人員徹底脫離數據持久這片剪不斷理還亂的苦海。
關于o/r mapping或者近來比較熱門的o/x mapping（大家可以參考“程序員，2004.01，p86”），可能需要專門的文章進行詳細論述，本文的目的主要是對現有方案的優缺點進行簡單剖析以及提供一些實踐中的參考信息。
相比較j2ee平臺，.net下的o/r mapping可謂沒什么歷史，至今還尚未有經過考驗的成熟的可用方案。但是，隨著各大廠商的重視以及開源項目的如火如荼，.net o/r mapping的步伐也開始慢慢跟上，使這塊本屬于j2ee的領地加入了新的競爭對手（會不會使更多的開發人員投入.net陣營？j），也讓眾多疲于在sql clause或ado.net中來回奔命的dal開發人員看到了“光明之路”。
接下來，就讓我們一起看看在這片比ado.net更廣闊的土地上有些什么值得探討的solution。
ø open source
開源方面一直與.net保持一定距離，o/r mapping更是寥寥無幾，但就作者的下載試用和源碼分析來看，個人以為如下的兩個解決方案還是有一定參考價值的：opf，ojb。
有關這兩個開源項目的簡介，大家可以參考“程序員，2004.01，p13”。
opf的全稱是：object persistent framework。
ojb的全稱是：object relational bridge。
在實現手法上，這兩個方案的思路完全不同，具有各自的代表性。
opf走的路線有點類似于typed dataset或borland eco（請參考下面的介紹），實現比較簡單，提供更多的源碼級控制；而ojb的實現則類似于microsoft objectspaces（請參考下面的介紹），采用了配置文件的方式，相對就比較復雜了。
這兩個方案的基本框架如下所示：
opf：
從圖中不難看出：
（1） persistent類扮演了dataset的角色，除了常規的對象數據操作外，還可以設定不同對象間的關系（如主從關系，集合關系等，這一點在borland eco所生成的代碼中也可略見一二），這也是上文所說“提供更多源碼級控制”的原因所在；
（2） persistentsqldatamanager則扮演了dataadapter的角色，通過預先設置的commands來執行真正的數據庫操作；在實際撰寫的employee data manager中，開發人員確實需要提供基本的sql語句，就像在sqlcommond中設置的那樣（borland eco則更進一步，以ocl代替了sql）；
（3） objectbroker的作用非常重要，它是對象與數據間的橋梁，registerpersistent方法建立了這種虛擬（object）與現實（rdbms）間的關系；
（4） 在employee business object的聲明中，對象屬性與數據庫字段的對應關系是通過.net attribute機制體現的，所以修改起來還是比較方便的，雖然相比配置文件的方式顯得不夠靈活（請參考ojb的介紹）,比如：需要重新編譯，開發人員不得不關注數據庫字段等。
ojb：
從圖中不難看出：
（1） 該方案的實現比較復雜，但用戶需要實際撰寫的代碼變少了（只需要編寫employee business object），這其中的關鍵就在于引入了配置文件；同時，由于配置文件的引入，我們在hello world application中也不需要調用類似opf解決方案（請參考上文的opf類圖）中的registerobject方法，所有這一切（甚至包括數據庫連接信息），系統都已了如指掌！
（2） 該方案中，sql命令通過criteria類被徹底替代，而queryfacade則充當了adapter的功能，通過persistencebroker這一真正的command與數據庫進行通信；
（3） 無論是repository.xml配置文件，還是criteria、queryfacade類，我們都可以在objectspaces（請參考下面的介紹）中找到類似的實現（難道是巧合？），同時，作者個人以為，這種方式也更符合o/r mapping的精神，減輕了開發人員的負擔！
（4） ojb還有一個非常cool的工具“repositorygen.exe”，可以用來生成repository.xml配置文件（同樣的，源碼無償奉上j），這一點，甚至連objectspaces都沒能做到（想想那么多字段、屬性、關聯、映射，簡直可以讓人發瘋j）！
