剖析 .Net 下的數據訪問層技術（四）
2024-07-10 13:05:06
供稿：網友
ø microsoft objectspaces
這是一個在幾年前就讓眾多.net guy伸長脖子激動不已的技術。就作者來說，那個時候，只要一提起這個話題，一般都是在j2ee guy的嘲笑聲中悻悻而歸，恨不能自己也搞個enb（相對ejb）或者ncmp（相對cmp）什么的。
終于，我們可以在.net framework 1.2（可在vs.net 2004whidbey或yukon中找到，目前都是beta版本）中一睹其“芳容”了j。
首先，讓我們看看用objectspaces寫出的代碼是什么樣子（依然使用上面的employee例子）：
// 初始化objectspace
sqlconnection conn = new sqlconnection("data source=localhost;
integrated security=sspi; database=northwind");
objectspace os = new objectspace("map.xml", conn);
// 根據employeeid返回其title
employee oemp = (employee)os.getobject (
new objectquery(typeof(employee), "id = 1"));
// 注意：實際字段名為：employeeid
string strtitle = oemp.title;
……
// 根據 city 返回所有符合條件的 employee
objectset oset = os.getobjectset(
new objectquery(typeof(employee), "city = '”seattle'"));
// 注意：返回的不是datatable，而是對象集合
foreach (employee oemp in oset)
{
…… // 注意：在這里可以對oemp做任何操作
｝
針對上面第二段代碼，還有一種解決方案，就是以objectreader替代objectset，這其中所包含的差異，類似于ado.net 1.0（包含objectspacesd的ado.net又稱為ado.net 2.0）中的dataset / datatable與datareader間的不同（不得不佩服microsoft在前后一致性上表現出的老謀深算j）。
仔細分析上面的代碼，就可以發現它和前面討論的ojb有驚人的相似點（ojb中作者只畫了基本類圖，但足可看出這種思想上的接近）！
例如：objectspace類基本上提供了ojb中的queryfacade功能；objectquery類基本上提供了ojb中的criteria功能；同時，兩種解決方案又不約而同的使用了配置文件來存儲o/r mapping信息；而應用程序一般也就通過這2個類進行數據操作，非常方便。稍微有些區別的可能是在數據返回格式上（這一點，objectspaces考慮得更細致，可以參考上面的代碼），但這已經對實際的代碼實現影響不大了。
如果將objectspaces下的調用代碼與前面給出的那段在ado.net下撰寫的代碼作個比較，不難看出，objectspaces給出的代碼更易閱讀和理解，就算不熟悉ado.net整體架構的開發人員，也可輕松上手（唯一涉及rdbms的代碼只有建立數據庫連接時需要）。對于已經熟悉ado.net或曾接觸過o/r mapping（如：j2ee下的hibernate）的朋友來說，真可謂小菜一碟！
從.net framework 1.2文檔中可以知道，objectspaces總共提供了3個命名空間，整體結構非常清晰：
system.data.objectspaces
system.data.objectspaces.query
system.data.objectspaces.schema
objectspaces、query已在上面的代碼中見識過，從名字中可以猜出，它們主要負責向外提供基本訪問接口（如查詢、增 / 刪 / 改等）和解析各種查詢條件（如對象過濾等），schema命名空間則主要用來操作o/r mapping配置文件，并為其它兩個命名空間中的類提供服務。
在objectspaces中，o/r mapping配置文件主要指map.xml，這個文件的名字是可以隨意更換的，比較類似ojb中的repository.xml。另外兩個分別描述數據庫結構和對象結構的配置文件也非常重要：rsd.xml（relational schema definition），osd.xml（object schema definition）。可以將它們理解為typed dataset中的xsd文件，沒有它們，所有的數據 / 對象mapping和validation都將是“非法”的j！
本文中，作者不準備對objectspaces來個深度探索，也不會提供什么sample說明其優越性，這方面，.net framework sdk早已為大家提供了豐富套餐。
作者只是希望，如果從dal的角度來分析，objectspaces技術能為我們帶來什么，是否意味著從此告別datareader / dataset，抑或為開發人員帶來了新的煩惱？
好處不多說，僅舉數例即可明了：
（1） objectspaces全部采用對象方式訪問數據，大大緩解了很多開發人員的sql（或者說rdbms）恐懼癥；
（2） 對于比較簡單的數據庫結構變化，只需要修改配置文件即可，無需重新編譯代碼（較之opf中將映射關系以.net attribute方式封裝于代碼中，顯得更加靈活、方便）；
（3） 對于比較復雜的數據庫結構變化，由于只涉及對象操作，所以修改的工作也要比以前簡單許多；
（4） 采用了o/r mapping配置文件后，數據庫設計與dal開發可以分別進行，相互的影響也降到了最低點；
不足則是我們更須關注的話題：
（1） 目前版本不支持中文（永遠的話題j）查詢，不爽！
（2） 當前版本僅支持sql server 2000以上版本的數據庫系統，弱（這是個很耐人尋味的限制，有興趣的讀者不妨想想到底是什么原因）！
（1、2引自.net framework sdk document，就這兩點已排除了很多躍躍欲試的朋友。而作者參與的.net項目雖不受1影響，但由于經常使用oracle，就不得不暫時忍痛割愛了j）
（3） 性能問題。雖然objectspaces也提供了類似datareader的功能（objectreader），但畢竟需要進行一次數據強類型填充，無論如何會有損失，如果返回數據量變大，將是一個不得不考慮的問題；
（4） 還是性能問題。map.xml是個好東東，但如何優化對它的訪問以及進行正確的validation（基于rsd.xml、osd.xml）畢竟需要時間，甚至在某些時候（數據庫結構比較復雜），這會造成比第3點更為嚴重的后果；
說了些不足，其實也無須過于擔心，畢竟，沒有十全十美的解決方案，怎么取舍就看你自己的決定了。
本章最后，作者給出了一個自己的總結，可供您參考一二。在所有的分析完畢之后，作者也試圖結合自己的實踐提供“我的方案（撰寫中）”，希望能給各位讀者帶來幫助。
