Microsoft ObjectSpaces 這是一個在幾年前就讓眾多
NET guy伸長脖子激動不已的技術
就作者來說
那個時候
只要一提起這個話題
一般都是在J
EE guy的嘲笑聲中悻悻而歸
恨不能自己也搞個ENB（相對EJB）或者NCMP（相對CMP）什麼的
終於
我們可以在
NET Framework
（可在VS
NET
Whidbey或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 =
));
// 注意
實際字段名為
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
（包含ObjectSpacesd的ADO
NET又稱為ADO
NET
）中的DataSet / DataTable與DataReader間的不同（不得不佩服Microsoft在前後一致性上表現出的老謀深算J）
仔細分析上面的代碼
就可以發現它和前面討論的OJB有驚人的相似點（OJB中作者只畫了基本類圖
但足可看出這種思想上的接近）！
例如
ObjectSpace類基本上提供了OJB中的QueryFacade功能
ObjectQuery類基本上提供了OJB中的Criteria功能
同時
兩種解決方案又不約而同的使用了配置文件來存儲O/R Mapping信息
而應用程序一般也就通過這
個類進行數據操作
非常方便
稍微有些區別的可能是在數據返回格式上（這一點
ObjectSpaces考慮得更細致
可以參考上面的代碼）
但這已經對實際的代碼實現影響不大了
如果將ObjectSpaces下的調用代碼與前面給出的那段在ADO
NET下撰寫的代碼作個比較
不難看出
ObjectSpaces給出的代碼更易閱讀和理解
就算不熟悉ADO
NET整體架構的開發人員
也可輕松上手（唯一涉及RDBMS的代碼只有建立數據庫連接時需要）
對於已經熟悉ADO
NET或曾接觸過O/R Mapping（如
J
EE下的Hibernate）的朋友來說
真可謂小菜一碟！
從
NET Framework
文檔中可以知道
ObjectSpaces總共提供了
個命名空間
整體結構非常清晰
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
抑或為開發人員帶來了新的煩惱？
好處不多說
僅舉數例即可明了
（
） ObjectSpaces全部采用對象方式訪問數據
大大緩解了很多開發人員的SQL（或者說RDBMS）恐懼症
（
） 對於比較簡單的數據庫結構變化
只需要修改配置文件即可
無需重新編譯代碼（較之OPF中將映射關系以
NET Attribute方式封裝於代碼中
顯得更加靈活
方便）
（
） 對於比較復雜的數據庫結構變化
由於只涉及對象操作
所以修改的工作也要比以前簡單許多
（
） 采用了O/R Mapping配置文件後
數據庫設計與DAL開發可以分別進行
相互的影響也降到了最低點
不足則是我們更須關注的話題
（
） 目前版本不支持中文（永遠的話題J）查詢
不爽！
（
） 當前版本僅支持SQL Server
以上版本的數據庫系統
弱（這是個很耐人尋味的限制
有興趣的讀者不妨想想到底是什麼原因）！
（
引自
NET Framework SDK Document
就這兩點已排除了很多躍躍欲試的朋友
而作者參與的
NET項目雖不受
影響
但由於經常使用Oracle
就不得不暫時忍痛割愛了J）
（
） 性能問題
雖然ObjectSpaces也提供了類似DataReader的功能（ObjectReader）
但畢竟需要進行一次數據強類型填充
無論如何會有損失
如果返回數據量變大
將是一個不得不考慮的問題
（
） 還是性能問題
map
xml是個好東東
但如何優化對它的訪問以及進行正確的Validation（基於RSD
xml
OSD
xml）畢竟需要時間
甚至在某些時候（數據庫結構比較復雜）
這會造成比第
點更為嚴重的後果
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26147.html
