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

來源:互聯網
上載者:User
訪問|資料 l 引言

自從 .NET 真正走入開發人員那天起,“效率”兩個字就一直成為眾多程式員津津樂道的話題。無論是從開發模式(Cross Language)、系統架構(.NET Framework),還是各種使用方便的工具(VS.NET),無一不體現出了它的勝人一籌。

同時,在另一方面,.NET 是否可以真正勝任企業級應用(Enterprise Application)開發的重任,卻依然爭論不斷,褒貶不一。

通常來說,對於一個企業級應用,需要考慮的方面很多,如安全、效能、伸縮性、易用性等。在本文中,作者更願意與大家一起探討 .NET 下資料訪問層的相關技術,這可能是在多層架構(n-Tier Architecture)誕生之日起就受到廣泛關注的敏感話題,而對於大部分開發人員來說,這也可能是項目中最讓人沮喪的部分,甚或引起爭議最多的部分。

在以下論述中,為統一起見,作者暫時將資料訪問層簡稱為DAL(Data Access Layer)。

l 分析問題

簡單統計分析後,就不難發現,DAL之所以讓人畏懼,並非出於技術本身的問題,甚至恰恰相反,很多開發人員認為這是最沒有技術含量的部分之一(就作者經曆的大小項目來看,該層所佔的開發時間一般較短,也是很多開發人員不願意承擔的“苦差”),只是架構需要或者某些思想作怪(如:為DAL而DAL)才加入了這所謂的第四層(傳統三層架構並沒有提出DAL思想)。

DAL的提出,確實對傳統的架構模式提出了巨大挑戰,加入的目的肯定也是希望借其進一步提高生產效率,在這種模式下,理想情況是:大部分開發人員從此擺脫DBA之苦,甚或徹底斷絕與資料庫的直接關係,SQL之痛將離我們而去,整個OO世界從此清靜。

不過,理想歸理想,能否成為現實則需通過項目檢驗。



接下來,作者試圖分析比較流行且較有代表性的幾種解決方案,看看能否從中得出一些有價值的結論,並為我們今後在設計與實現DAL時提供一些借鑒。



u ADO.NET

首先,提到.NET下的DAL,立刻映入眼帘的就是ADO.NET。

沒錯,幾乎所有的DAL解決方案(請允許作者使用Solution而非

Framework)都必須從它發展而來,沒得選擇,這也是具有.NET特色的

實現方式(相比較J2EE)。

排除商業因素及CLR本身的需要,ADO.NET真正帶給我們的東西

不多,值得一提的也就DataSet(就作者經曆的項目來說,使用更多的是

DataTable和DataView)。從微軟早期的記憶體資料庫(Memory Database)

鮮有人問津到今天的DataSet大行其道,這其中的曲折實非片言隻語所

能道盡,總之,有一點可以肯定,正是有了DataSet這種選擇,.NET下

的DAL才能象今天這般百花齊放,大家的思路才能更趨開闊。



Duwamish

這方面有很多好的Sample,最經典的莫過於微軟大力推薦的企業級開發套餐:Duwamish。

對於希望學習.NET下DAL設計的朋友,這是一個不錯的起點,這

方面的完整剖析,大家可以參考“CSDN開發高手,2003.11”,本文不

再贅述。

作者自己參與的一個項目中就使用了Duwamish方案,當時限於工

期,感覺這是一個很好的參考,沒做深入分析就開始設計了。現在回想

起來,發現還是有很多不足之處。

舉個簡單的例子,Duwamish方案中並沒有考慮Cache Management,

而這對於企業級應用來說,某些時候就是一個不得不考慮的問題;另一

方面,雖然Duwamish中告別了SQL語句(全部採用預存程序實現),

但資料庫痕迹依舊十分明顯,比如:某些欄位名稱的定義,關聯表名稱

的定義等等。

還有一個十分頭疼的問題是在開發過程中體現出來的。一開始,那

些比較簡單的資料表還比較容易實現,到了一些包含相互關係的資料表

時,我們的DAL工程師就感到了壓力,到後來,幾乎又做了一遍DBA

在資料庫建模時早已做過的工作,只不過,這次將資料庫指令碼換作了

C# 實現(或者說:將資料庫結構換成了表面上具有OO特色的DataSet)

而已。

可能,Duwamish的實現比較經典,但在實際應用中,有時並不意

味著Best Practice。就拿我們的項目來說,雖然成功交付,但無論從模

型複用角度,還是開發效率來說,都不能算很成功。套用一句流行語:

其實我們可以做得更好!



PetShop

ADO.NET上另一個值得參考的DAL實現就是鼎鼎大名的PetShop。

當然了,與Duwamish相似,名氣大未必真的實用。PetShop雖然

彌補了Duwamish在某些方面的不足,例如:通過Factory支援多種數

據庫儲存,引入了Cache機制,提供了更為便利的SQL Helper,但也同

時帶來了另一些問題。其中,最麻煩的就是SQL語句的引入,而且還

是針對不同資料庫儲存的不同SQL語句(主要是SQL Server與Oracle

的參數表示方式不同)。

另一方面,PetShop雖然沒有使用DataSet而代之以更為簡潔的普通

實體物件(Model),但它還是將DataReader的結果轉換到了包含實體對

象的列表集合中供離線使用,從這個意義上說,可謂換湯不換藥。甚至,

在某些場合,例如:需要進行資料過濾,或者在主從資料間導航,反而

更為不便(此時,簡單的Collection或者List是無法滿足需求的,DBA

與DAL開發人員只能再提供其它的方法來達到目的)。



從上述兩個例子中,我們可以看出,即使在微軟的Team Dev中,也

沒有能夠在DAL這個問題上達成一致。這方面的更詳細資料,有興趣

的朋友可以參考如下文章:

http://www.microsoft.com/china/community/Column/67.mspx。



實戰

上面剖析的兩個解決方案,讓我們看到了它們各自的優勢與不足,而企業級應用的複雜環境也不太可能要求一個放之四海而皆準的架構就能解決所有難題,因此,只能根據具體情況具體分析。

作者曾經參與一個(.NET)大型外包項目的開發工作,有幸一睹其DAL的設計思想,深感震撼,在此與各位朋友一起共同探討。

以SQL Server所帶Northwind資料庫為例,如下就是一段基於該DAL的調用代碼(作者做了一些名稱上的調整):



// 根據EmployeeID返回其Title

boEmp = new EmployeeDAL();

boEmp.Keys[“Emp_ID”] = 1; // 注意:實際欄位名為:EmployeeID

boEmp.Select();

string strTitle = boEmp[“Emp_Title”]; // 注意:實際欄位名為:Title

……

// 根據 City 返回所有合格 Employee

boEmp = new EmployeeDAL();

boEmp.Keys[“Emp_City”] = “Seattle”;

boEmp.Select(); // 注意:該方法與上面的調用完全相同

DataTable dtEmp = boEmp.Table;



如果不考慮對象建立(可以採用Object Pooling或者Cached Object)以及調用後的處理,實際的代碼只有兩行!

更讓人吃驚的是,上述EmployeeDAL類沒有任何真正意義上的實現代碼,僅僅是聲明了類名,然後從一個通用基類繼承而已!!

最優雅的地方還不在於此,實際上,就算在那個基類中,也根本看不到SqlConnection或者OracleAdapter之類的幫派之爭。

相信大家也猜出來了,沒錯,它是借鑒了PetShop的實現,採用了Factory模式來保證DAL可以適用於不同的資料庫儲存。不過,這種實現與PetShop還是有很大的區別:至少,它沒有產生不同的SQL語句,更沒有出現不同的參數調用方式(SQL Server中一般使用“@”符號,Oracle中一般使用“:”符號),所有幫派一視同仁!

這其中,當然得益於Factory的實現技巧,但更重要的因素還在於設計方式的精妙。其實,在.NET Framework中,已經提供了這種設計方式的基石,說白了,就是System.Data中的那些Interface(如:IDBConnection,IdataAdapter等)。

在這樣的設計基礎上,我們針對每一個DAL類,就不再需要為不同的資料庫儲存提供不同的資料存取實現了。例如:在PetShop中,針對訂單資料需要實現Order類,很自然的,系統為SQL Server與Oracle分別實現了Order類並使用不同Provider(SqlClient,OracleClient)提供的方法進行操作。而在實際調用時,PetShop通過Factory模式動態建立真正的Order類並啟用相應的方法,一個面向不同資料庫儲存的方案就躍然紙上。

其實,PetShop這種方案已經比較靈活了,如果更能省去“撰寫不同Order類”之苦,那就真的送佛送到天了J。而所有這些功能,在作者所參與的這個項目中,已經完全搞定了!

至於上面的“EmployeeDAL(當然,包括其它所有DAL類)沒有任何真正實現代碼”,只不過玩了一個小小的配置技巧而已:將不同的DAL類與相關的Stored Procedure(請注意:不是Table或View)按照Namespace分別儲存到XML檔案中。

可能大家已經看出來了,理論上,甚至只需要一個DAL類就可以完成上述所有的工作!但在實際操作中,不同的DAL類可能還是有一些資料處理上的細微差別(比如:資料校正,格式轉換等)。

總的來說,在這樣一個大項目中,不可能要求所有開發人員(除了DBA,DAL Framework Developer)都去瞭解ADO.NET的方方面面,雖然作者對此頗有研究,但在這個項目中,卻從頭至尾只用到了兩個類:DataTable,DataView(甚至連Transaction都無需瞭解)!



相關文章

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。