告別ADO.NET實現應用系統無縫切換的煩惱(總結篇)
2024-07-10 12:38:26
供稿：網友
可能只是那么想也是那么設計的，要支持多數據庫，要能支持多數據庫，萬一要是以后數據庫變了怎么辦？萬一要是。。。怎么辦？這些顧慮很多時候是不必要的，反而繞了彎子。大都是做項目應用系統而非產品，即使要用不同的數據庫了，基本上是吧上一個項目全COPY過來，修修改改OK了。產品可能就不一樣了，那才可能要支持真正的多數據庫，才可能會面對真正的數據庫訪問類庫的多數據庫的實際檢驗。ADO.NET2.0下增強了數據庫訪問的功能，也就是工廠式類庫，提到工廠式數據庫訪問，網上可就多了，ADO.NET2.0增強的工廠式網上也很多了，都說只要改動webconfig里的數據庫連接就行了，其它什么地方都不用改了，看了幾篇都是點了下，不知道做過充分測試沒有，應該說在實際的多數據庫產品系統中，還要做很多修正，完善和測試的。
說正題，假設（只是假設，真的不會這么變態，呵呵）一產品系統要支持ACCESS,SYBASE,SQL SERVER,ORACEL數據庫，系統開發完后，要求只改動數據庫的連接，也就是說只改動webconfig，來實現系統的無縫切換，其它什么也不改動，可能有的覺得簡單，但是要經得起實際檢驗還是要花點時間測試的，當然寫是不算難，見到過有的應用系統開發中，所有的DML語句都以XML形式放在config配置文件里，然后用封裝好的數據庫訪問組件讀config配置文件執行SQL語句，開發人員只要建個config文件把增刪改查語句寫那里就可以，當然這么來有個好處，就是做到了與數據庫的無關性了，如果數據庫訪問組件做的完善的，當然是可以做到系統無縫切換到其它數據庫的，當然同時也有缺陷，項目中不僅僅是DML語句吧，有的稍微復雜點的邏輯，存儲過程要用下吧，我自己也趨向于喜歡用存儲過程，自定義函數來處理稍微復雜的邏輯，而且把DML語句都放在配置文件里我也是不能忍受的，可能是一個個人的習慣吧。
繼續，下面開始我要說的利用ADO.NET2.0及以上版本新增的工廠式數據庫訪問實現應該系統的無縫切換，要實現無縫切換，當然還是要有前提條件了，就是各個不同的數據庫之間的表和其它對象都已經成功移植了，沒有這個前提，純用ADO.NET做系統無縫切換那是不可能的了，比如SQL SERVER中寫的存儲過程，自定義函數直接復制到ORACLE上就行了嗎？當然是不行，寫法及變量定義要做些調整才可以成功移植的，還有變結構字段類型等等的都可能是要做相應調整，這些都做好了才能談系統的無縫切換。要做的無縫切換，數據庫訪問層的代碼中最好（并非絕對）不應該出現SqlCommand，SqlDataAdapter,SqlClient,SqlXXX吧，要切換到ORACLE數據上，甲骨文會把你的SqlXXX玩死的，ORACLE里可以OracleCommand，OracleXXX，還有程序執行帶參數語句時，比如 where userid=@userid，甲骨文也會玩死你的，oracle里可是where userid=:userid，@前綴在ACCESS,SYBASE,SQL SERVER里是都認得，還有還有字段名的寫法問題，ORACLE里可以區分大小寫的，比如可能大多習慣這樣命名屬性和自段,UserName,UserAge，如果在ORACLE里這么命名的話，系統開發過程中的那種痛苦也許只有經歷過的人才知道，ORACLE堅持大寫為標準，記得很久很久以前的一個夏天的晚上，那時我還是年輕的80后，一位數據庫設計比較N的人提到過，盡量在數據庫設計和T-SQL編程中采用大寫標準，基本上接觸的SQL SERVER數據庫較多，也習慣了表名，字段名的大寫設計，后來發現確實是有道理的。這里提到的問題都是在下面的各個方法中為了兼容不同的數據庫需要面對的問題，具體講到每個執行方法時再具體解釋。剛才說SqlCommand,OracleComand都是各自認得，但是DbCommand可是大家都認得的，暫且叫抽象對象吧，還有DbConnection，DbDataAdapter等都是他們都認得的，所以在做支持多數據庫訪問類庫時，就可以用這些對象了，根據這些對象再創建具體對象。ADO.NET2.0中數據庫訪問工廠中有個 DbProviderFactory 對象，也就是通常說的DataProvider了，正是這個起了關鍵和方便的作用，是用來創建提供程序對數據源類的實現的實例（就是用來創建實例）。另外數據庫操作還要用到參數吧，DbParameter，DbParameterCollection下面都需要用到，先貼一段類庫的構造函數，因為共用對象需要先實例化。
