常用的資料訪問方式

我瞭解的常用的資料庫訪問方式（.Net環境）有以下幾種：

1， 直接使用.Net提供的各種DataAdapter或DataReader

2， 使用資料訪問控制項（各種DataSource控制項）

3， 自己寫的訪問類（一般指的是自己封裝後的DataAdapter或DataReader）

4， 使用ORM架構

當然以上並不是包含所有的資料訪問方式，但是常用的也就這幾種。

資料訪問的方式的選擇很大一部分是依賴於構架的設計，相互之間也不一定是互斥的關係。比如說第二、三、四種方式其實都依賴於第一種，但是在某一定程度上作了封裝。而且各種訪問方式不一定有誰好誰壞的差別，更多的是適合於不適合。

下面詳細說說我對幾種資料訪問方式的看法。

第一， 直接使用.Net提供的各種DataAdapter或DataReader。

這種方式相信大家都會。每一本講.Net資料訪問的書中都會這樣告訴你：建立資料連線，建立Adpater或Command，開啟資料庫連接，執行資料訪問，關閉資料庫連接。這是ADO.Net的官方標準流程。

然而在實際生產中呢？

對每一個資料庫訪問都採用以上的過程嗎？都寫一大堆Try…Catch？連接字串放在哪兒？資料存取碼放在哪兒？怎麼實現資料來源的可替換性？怎麼測試？怎麼處理並發？如果需求變了怎麼辦？更重要的是，對於每一次資料訪問都要考慮以上問題嗎？

顯然，直接使用DataAdapter或DataReader不是一種良好的設計，要對以上過程在一定的程度上進行封裝和抽象。這樣也就有了以下幾種資料訪問方式。

第二， 用資料訪問控制項（各種DataSource控制項）

微軟為我們封裝的資料訪問控制項。主要特點是快！在Vs.Net開發環境中，從資料庫中拖一個資料表到WinForm或Web頁上，自動就會產生相應的資料訪問控制項，包括相應的Select、Update、Insert和Delete命令。

資料訪問控制項和Vs.Net的配合可以說是完美，兩者的結合把RAD發揮的淋漓盡致。基本上建立好資料庫，點幾下滑鼠，你就可以有一個能用的使用者介面了，甚至加上顯示控制項的AutoFormat功能，還能讓你的資料介面具備一定的觀賞性！所有的DataAdpater、DataReader、各種借口、容器、設計模式、構架、物件導向……統統忘了吧！甚至SQL語句你也可以不會！需要做的就是處理一個又一個的頁面，拖放一個又一個的控制項。當然有些複雜的東西還是需要稍作調整的，比如多表聯集查詢，不過也不要緊，DataSource還能結合Query Builder使用呢！好開心呀！

不過等等。當你吹著口哨，唱著小曲，身心愉悅的拖著控制項的時候，頭說了：某某需求變了，某某表也要變了。噢，天！我早就記不清那些控制項用到那個表了！一個個的檢查？我的WebSite裡面有幾十個aspx，上百個DataSource……。然後，當我剛剛改好，筋疲力盡的時候，頭又說了：客戶要求……，……，……，……。

如果從物件導向設計的角度分析一下的話，幾乎所有的代碼臭味都能用在這個系統上。簡直就是反面教材呀！

那難道說這種方式也被無情的拋棄了，也不盡然。快有快的好處，以下情況適合採用這種方式（或者說，以下情況適合RAD方式）：

1， 原型系統：為了驗證客戶需求而編寫原型，幾乎不用考慮代碼演化的問題，作為客戶需求的說明和正式開發的參考為存在的。如果客戶提出了新的需求或需求發生了變化，就編寫新的原型系統。原型系統作為可編譯、可啟動並執行客戶需求而存檔。

2， 一次性的代碼（Write Once，Use Once）：比如要求對資料庫進行一些硬性的修改或維護的時候。這些代碼執行了這一次操作之後，就失去了存在的價值。

3， 永遠不會變的系統：很好理解。問題是，這樣的系統，存在嗎？

4， 作業：老師布置的作業，通常的特點是：簡單、不會有大變化、注重結果、容易矇混過關（^^）。

第三， 自己寫的訪問類（一般指的是自己封裝後的DataAdapter或DataReader）

真真正正的物件導向的資料存取方法，看下面的圖：

商務邏輯定義資料訪問，DAL實現，有點類似於Adapter模式。商務邏輯和資料訪問進行了良好的解耦合，資料訪問層的實現依賴於商務邏輯，符合實現依賴於抽象的原則。

這種方法的好處很顯然：高度解耦合、容易更改、適合團隊開發。不過也不是沒有缺點，那就是工作量要大一些，特別是當業務實體的類型較多時，可能總要重複的實現SELECT、INSERT、UPDATE、DELETE等。不過既然商務邏輯不依賴於資料訪問，我們也完全可以變通一下，比如用代碼產生加手工修改的方式，結合強型別的編譯特點，修改起來還是比較方便的。

這種方法還有一個很重要的好處，解耦合的好處就是便於測試！進行測試時完全可以類比一個資料訪問層，單獨對商務邏輯進行測試，甚至可以類比各種資料庫錯誤的情況！同時亦可以單獨對資料訪問層進行測試！

這種方式如果需要更換資料庫的話，也是比較容易的，基本上一種資料庫的訪問可以封裝一個DLL，根據系統的情況，部署的時候修改一下設定就可以了！

對了事務、特別是分散式交易等要求，可以在“統一的資料訪問入口”這個位置實現。對於上層來說，是透明的。

這種方法是我最常用的方法，推薦！

第四， 使用ORM架構

這個就不說了吧？在園子裡搜一下，肯定一大堆，慢慢看吧！^^