.NET - 連接數據源的最佳實踐？

我正在構建將使用SQL Server後端存儲持久性數據的客戶端應用程序。在過去，我一直使用連接字符串來完成這項工作，通常是我在註冊表中存儲的連接字符串。然後，我查找該註冊表值並使用它來啓動我的SQLConnection。.NET - 連接數據源的最佳實踐？

但是，我想知道這種方法是否是最佳實踐？想到的另一個選擇是在可以訪問數據存儲的客戶機上創建一個System ODBC連接。這將是一個更好的解決方案，因爲連接字符串不太明顯，但這也意味着需要在安裝了客戶端的每臺計算機上創建ODBC連接。

如上所述，連接數據存儲的最佳做法是什麼？

來源

2012-01-24 user1166145

您的客戶端應用程序是雙層架構。最佳做法是使用Windows身份驗證（連接字符串中的"Trusted_Connection=yes"）。

您可以通過創建組來管理客戶端訪問，將所有用戶放入該組，然後爲組提供針對SQL Server數據庫所需的權限。

Choosing an Authentication Mode：

當用戶連接通過Windows用戶帳戶，SQL服務器使用Windows主體令牌操作系統驗證帳戶名和密碼。這意味着用戶身份是由Windows確認的。 SQL Server不要求輸入密碼，並且不執行身份驗證。 Windows身份驗證是默認身份驗證模式的，並且比SQL 服務器身份驗證安全得多。 Windows身份驗證使用Kerberos安全協議，爲強密碼提供密碼策略實施方面的複雜性驗證，爲帳戶鎖定提供支持，並支持密碼過期。使用Windows身份驗證進行的連接有時稱爲可信連接，因爲SQL Server信任由Windows提供的憑據。

來源

2012-01-24 02:08:48

這是一個很好的主意。在上述情況下，您通常會將該連接字符串存儲在註冊表中還是XML文件中？儘管我認爲從長遠來看這並不重要。 – user1166145

這並不重要，因爲它不包含敏感信息。只是服務器和數據庫的名稱。所有訪問權限都在一個安全的中央位置（AD）中管理 –

我使用LINQ to SQL，可能不是大型數據庫最有效的方法，但如果您熟悉OOP，它將很容易學習和強大。

對不起，我以爲你在談論數據庫框架，在你的情況下使用Windows認證，就像Mitch說的那樣。

來源

2012-01-24 02:09:59

海報正在討論連接字符串和身份驗證，而不是數據訪問框架... –

通常，如果我創建的應用程序將連接到中央SQL數據庫，我使用Windows/AD身份驗證來處理連接字符串的身份驗證部分。服務器FQDN或IP是硬編碼的。

或者，如果這不是一個選項，那麼最好創建應用程序將與之交互的某種服務，而不是直接連接到數據庫。

請記住，這些只是一般指導原則。如果你正在談論一個公司內的幾個用戶的專門構建的應用程序，那麼這可能都是矯枉過正的。基本上它取決於你的目標受衆和要求。

來源

2012-01-24 02:10:07

.NET - 連接數據源的最佳實踐？

回答

相關問題