在.NET中訪問數據的最佳實踐（非MVC）

Question

我使用.NET 3.5，查看其他人完成的舊代碼並試圖添加安全性並對其進行更新。

什麼是在Web窗體項目中訪問數據的最佳實踐？

目前我改變代碼使用SQL參數，就像這樣：

using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["defaultConnection"]].ConnectionString)) 
{ 
    using (SqlCommand myCommand = new SqlCommand(sql.ToString(), conn)) 
    { 
     myCommand.Parameters.AddWithValue("search1", mySearchVar); 
     ... 

我知道SQL中的參數化是很重要的，但我看到使用存儲過程的其他人呢？他們是否採用其他方式，遵循最佳做法？

Answer 1

如果它不只是小重構和你有時間來重寫你的數據訪問層，使用一些ORM：

NHibernate

Entity Framework

Dapper.NET（＃1 ORM）

BLToolkit

Answer 2

實體框架是一種「最佳實踐」，也是微軟推動力最強的一種。但是沒有最好的數據訪問方法。

在對EF和其他ORM的性能有一些不好的經驗之後，我通常完全避開它們，只是手工製作數據訪問代碼或使用代碼生成工具來輸出爲特定應用程序製作的代碼。

另一方面，有很多不好的做法，你通過轉向參數化避免了關鍵問題。

就我個人而言，除非您打算完全使用它們 - 即防止在存儲的特效之外進行任何數據修改，否則我目前在存儲的特效中沒有看到任何點。如果是這種情況，它可以爲您提供一些適合您的數據的修改類型。

所以這不是一個真正的答案 - 因爲真的沒有答案 - 你的問題開闢了一個大討論的話題。有時間購買一些書籍，或者忙於使用Google。

Answer 3

沒有什麼使用ADO.NET時出錯。這是驅動.NET中所有ORM解決方案的原因。然而，看起來.NET開發人員正在羣集地奔跑於ORM的潮流之中。 ORM只是數據訪問工具箱中衆多工具之一。

在2000年代初期，ORM通過風暴把Java世界帶走了。商店程序被避免。這是ORM或什麼都沒有。五年後，Java開發人員意識到最好的解決方案同時使用ORM和存儲過程，每個都有優勢。

使用最好的工具來完成這項工作。 ORM可以從應用程序中自動執行大部分CRUD。存儲過程適合添加抽象，增加一層安全性並優化需要高性能的區域。

選擇最適合這項工作的工具。