.NET下,你採用的是哪種方式進行資料操作?
這裡假設一個數據庫中有一張表,表名為Test,列為colID,colTest1,colTest2,colTest3。其中,colTest1,colTest2,colTest3為nvarchar(50),而colID為int;
一、資料介面卡+型別化的資料集
假設資料介面卡名為da1,資料集為ds1,資料集類為ds;
方法1:直接操作的情況,利用Index來對Rows物件陣列物件定位,此做法比較常見。
DataRow dr = ds.Tables[0].Rows[Index];
dr["colTest1"] = "test";
dr["colTest2"] = "test";
dr["colTest3"] = "test";
da.Update(ds);
方法2:當已知主鍵ID的時候,利用型別化資料集的特點,進行操作,這是MSDN中ASP.NET更新資料的教程中的作法(DataGrid的資料更新)
ds.TestRow row = ds.Test.FindByColID(id);
row.colTest1 = "test";
row.colTest2 = "test";
row.colTest3 = "test";
da.Update(ds);
方法3:修改與刪除的時候,利用DataView做為中間橋樑,進行資料修改後,再Update.
從寫程式碼的簡便性上來說,上面的方法二略優於方法一與方法三,利用visual studio.net的程式碼提示功能,可以提高一點效率。
但使用資料集資料繫結後,使用Update操作資料庫時,很容易遇到一些奇怪的情況,往往在進行頻繁的Fill與Update的時候,資料集明明是發生了更改,但資料庫中的值卻沒有發生更改或出現同步錯誤,而且解決資料庫衝突,往往還要花費一些附加的程式碼,這些程式碼由於是在各個事件中填寫,使得程式碼在觀感上,更難於維護.並且大量的類例項的建立,對效能也往往為造成一些不可估計的衝擊.Visual Studio.Net的資料介面卡嚮導,往往又充當邪惡的角色,很容易勾引你使用它產生大量的垃圾程式碼.
二、資料介面卡+非型別化資料集
方法1:建立一個空的DataSet資料集,直接用da.Fill(ds),來填充ds,讓它自動自成內部結構
方法2:繼承DataSet類,然後手工填寫程式碼,產生具體的實體類,再進行操作(如Duwamish的作法)
方法1是屬於,準備工作比較簡便,呼叫起來比較麻煩的,而方法2,是屬於做準備工作比較複雜雜的,呼叫起來比較輕鬆的那種。兩者的麻煩度差不多。
三、直接操作資料庫
即建立一個Connection與Command,然後對資料進行操作,如果有必要的情況,使用引數化命令,當然本方式,也指使用儲存過程進行呼叫的情況。
這種方法是最高效,粒度最細,控制最方便,使用上最安全的一種方法,但也是在code時最麻煩的一種,繁雜的CURD,可以讓開發者徹底陷入資料訪問的苦海,浪費大量的時間,極易讓人產生煩燥情緒。
四、採用Application Data Block
方法一:直接使用微軟提供的Data Block,利用SqlHelper類直接進行資料操作
方法二:也是使用微軟的Data Block,但按照自己的需要作過一定的更改(比如,設定公共的Connection屬性,以便不用每次都再寫一遍)
相對來說,這類方法比直接操作資料庫的方式要輕鬆一些,對於Connection的開啟與關閉,幾乎可以不作考慮,而且在採用事務進行資料操作時,編寫程式碼將顯得更為輕鬆。
五、利用O/R Mapping,進行資料庫更新
方法1:全部是由自己手寫程式碼或自己寫的元件
方法2:採用商業元件,如Devexpress公司的XPO等
方法3:採用開源元件,如Nhibernate 等
這三種方法,都差不多,但從風險的角度考慮,方法2略優於另外兩個方案,方法1需要大量的測試與驗證,否則寫軟體時,不得不承擔附加的風險,而方法3,如果.NET下的開源元件像JAVA中的那麼成熟的話,是完全可以採用的,但目前在專案中使用Nhibernate,風險性還是比較大的。方案二中,由於有專業公司的維護,加上某些商業元件本身的成熟度,在一定的程度上可以減少風險。
採用O/R Mapping,無疑是最快樂的開發方式,但是的目前的階段來說,目前在.NET下,採用O/R Mapping的方式寫程式碼,還是要冒一定的風險,而且效能上,也是被人所詬病的。
六、利用程式碼生成器
方法一、完成使用程式碼生成器生成的程式碼或dll,對其進行呼叫。
方法二、僅利用程式碼生成器產生儲存過程,經過測試後,然後自己手工寫程式碼呼叫。
方法三、將程式碼生成的器的程式碼進行簡單修改後,對其進行呼叫。
這可能是開發效率最高的方式了,但目前的程式碼生成器,在使用時,仍然是讓人提心吊膽的,風險度大大高於O/R mapping的方式,很多情況下,許多程式碼生成器,實際上就是自動生成一個O/R mapping層,用於隔離資料持久化與業務程式碼之間的屏障。雖然目前有不少看起來很不錯的生成器,但在使用時,還是要審慎一下才好。
以上所列出來的幾種方法中,從最穩定的角度考慮,應該是三、四,如果幾類方法間有所結合,我得出的如下結論:
(1) 綜合從效能的角度考慮,在有資料繫結的情況下,採用資料介面卡,進行資料填充與繫結,而資料庫的更新則採用三或四的方法,相對來說,比較理想.
(2)如果採用O/R Mapping的方案,對於資料更新可以採用O/R的方案,但資料的查詢等,還是採用SQL的方法進行,而不要考慮物件查詢,可以大大地提高方案的可用性(該思想是progame告知的).
這篇文章,是順手寫的,在思想上有些什麼不對之處,或者還有不完美善之處,希望大家能夠不吝賜教.