.NET下，你採用的是哪種方式進行資料操作？
阿新 • • 發佈：2019-01-17
進行資料庫進行更新操作時，有許多種方式，你使用的是哪種？
這裡假設一個數據庫中有一張表，表名為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告知的).
這篇文章,是順手寫的,在思想上有些什麼不對之處,或者還有不完美善之處,希望大家能夠不吝賜教.
這裡假設一個數據庫中有一張表，表名為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告知的).
這篇文章,是順手寫的,在思想上有些什麼不對之處,或者還有不完美善之處,希望大家能夠不吝賜教.