剖析 .Net 下的資料訪問層技術(四)

來源:互聯網
上載者:User
訪問|資料 Ø 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點更為嚴重的後果;



說了些不足,其實也無須過於擔心,畢竟,沒有十全十美的解決方案,怎麼取捨就看你自己的決定了。

本章最後,作者給出了一個自己的總結,可供您參考一二。在所有的分析完畢之後,作者也試圖結合自己的實踐提供“我的方案(撰寫中)”,希望能給各位讀者帶來協助。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。