Microsoft ObjectSpaces

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點更爲嚴重的後果；