剖析.Net下的數據訪問層技術(4)

2019-11-18 12:06:48

字體：大中小

來源：轉載

供稿：網友

　　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點更為嚴重的后果；

上一篇：剖析.Net下的數據訪問層技術(5)

下一篇：給.NET中的Windows窗體加載Xp樣式