<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Ø 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點更爲嚴重的後果；
說了些不足，其實也無須過於擔心，畢竟，沒有十全十美的解決方案，怎麼取捨就看你自己的決定了。
本章最後，作者給出了一個自己的總結，可供您參考一二。在所有的分析完畢之後，作者也試圖結合自己的實踐提供“我的方案（撰寫中）”，希望能給各位讀者帶來幫助。
作者簡介：
“本文作者張雪峯 是 畢博全球開發中心 的高級開發工程師。他目前在中國上海 畢博全球開發中心 Core/EAI 部門工作，從事 .NET 技術的研究以及相關項目的開發。可以通過 [email protected] 與他聯繫。”