.Net 應用程序：數據庫連接最佳實踐

Question

我是編程初學者，因為我有 0 次經驗：我從未開發過任何應用程序。 幾個月前，我開始使用 WPF/C# 和 SQL Server 數據庫開發桌面應用程序。

隨着我對數據庫更加熟悉，我做的第一件事就是創建我的數據庫以及所有表和關系。 我知道我不想在我的應用程序中包含我的查詢，所以我創建了 100 多個存儲過程，其中包含必須在我的應用程序中實現的所有邏輯。 現在我已經完成了我的 UI 的創建，我即將開始編碼，我要做的第一件事就是在我的應用程序和我的數據庫之間建立一個連接，我知道包含我的連接字符串不是一個好的做法，由於未來維護問題的風險，App.config 中的數據庫用戶/密碼。

我相信最好的辦法是在我的應用程序和我的數據庫之間有一個層，我可以在其中存儲連接信息，以便我的應用程序可以與該層以及與數據庫的層進行交互。 我的問題是：我該怎么做？ 我在這里看到了建議創建 WCF 服務的答案。 這對我來說就像一門外語，但我非常願意學習。 我想得到一些關於 0 編程經驗的人是否可以實現這樣的架構或者我應該放棄的反饋。 是否沒有具有此類實現的開源文檔？

其次，關於我的應用程序，我還應該了解其他最佳實踐嗎？ 例如：

1. 我已經實現了 RBAC 方法，但所有訪問控制都在我的存儲過程中實現。 這可以嗎？

2. 連接到應用程序需要用戶名和密碼。 這些信息存儲在我的數據庫中的一個表中。 我正在考慮加密密碼字段。

3. 該應用程序可以分發給多個客戶端。 我正在考慮實現三個不同的數據庫（測試、接受和生產，可能也在不同的服務器中）並且對於每個客戶端，我將在數據庫中創建一個特定的模式，以便每個客戶端都有自己的對象。 這樣，來自不同客戶端的數據之間永遠不會發生交互。 問題是向新客戶端提供應用程序需要自定義所有內容（架構、表、過程、功能等），但我覺得這可能會導致維護問題，因為每個更改都必須應用於每個客戶端的架構。

4. 關於DB連接，雖然可以在App.Config中包含連接字符串，但在Visual Studio中，也可以直接連接到DataSources中的DataBase。 最好的方法是什么？

我可能會錯過一些其他的東西，但如果能對這些問題有反饋，那就太好了。

Answer 1

現在我已經完成了我的用戶界面的創建

在閱讀本文之前，我以為您已經完成了后端的創建

我知道由於未來維護問題的風險，在 App.config 中包含我的連接字符串、數據庫用戶/密碼不是一個好習慣。

如果您不打算將連接字符串存儲在 app.config 中，那么您需要另一種身份驗證方式，例如 Windows 憑據。 或者您需要加密應用程序配置的部分。 與其說是未來的維護，不如說是關於安全性。 如果沒有將 db 連接詳細信息放在 app.config 中，則會造成更多的維護麻煩，因為在大多數情況下，事情的設計都是為了期望那是他們所在的位置。 當然，如果您願意，您可以將它們存儲在文本文件中或每次向您的用戶詢問它們

我相信最好的辦法是在我的應用程序和我的數據庫之間有一個層，我可以在其中存儲連接信息，以便我的應用程序可以與該層以及與數據庫的層進行交互。

與存儲連接詳細信息無關； 這聽起來像是您開始打破具有處理數據庫中對象的數據層和處理業務需要使用一個或多個數據層實體執行的操作的業務邏輯層的典型架構。 創建新帳戶將需要有關人員和地址的信息，數據層可能會將它們視為不同的事物，而業務層會將它們視為對特定流程至關重要的一件事

我怎么做？

大多數人通過將數據相關的事情推遲到像 EF 這樣的庫中來做到這一點，該庫對 db 及其包含的實體感興趣，並在代碼中對它們進行建模。業務目標，一組支持這些操作的數據存儲類，以及一組將業務對象映射到數據庫實體對象的過程； CreateAccountModel 由 UI 生成並傳遞給 AccountRepository 的 CreateAccount 方法； 在內部，帳戶存儲庫通過 db 上下文了解 DB 中的 Person 對象和 Address 對象，並將使用它在 CreateAccountModel 中找到的數據創建其中的一個。 這將創建帳戶的業務需求過程與存儲數據的事物斷開連接。 從概念上講，您可以將數據庫換成另一個存儲個人和位置而不是人員和地址的數據庫，而業務層並不關心。 閱讀有關該主題的內容； 沒有正確或錯誤的方法來做到這一點，因此提出基於事實的答案並不是一個容易的問題

我在這里看到了建議創建 WCF 服務的答案

WCF 是一個 Web 服務框架； 計算機可以代替人類使用的網站。 您可以肯定地插入這一抽象層，但實際上，如果您的用戶界面與您的數據存儲和處理中心相距甚遠，或者您的業務財務模型依賴於您將軟件作為服務提供給某人。 我不希望在本地使用並擁有自己的數據庫的 UI 需要通過網絡進行操作的復雜性，如果它所做的只是在本地機器上調用服務

我應該放棄嗎

這不是 SO 旨在回答的問題。 這不是經驗豐富的專業人士會問的問題

是否沒有具有此類實現的開源文檔？

有數百萬個項目和數以千計的架構； 這應該告訴您做某事的方法不止一種，最終正確的是主觀/意見。 如果它有效，並且不會崩潰並滿足客戶的期望，並且您的構建和維護成本沒有超過您支付的費用，那么您可以說它是正確的

其次，關於我的應用程序，我還應該了解其他最佳實踐嗎？

可能有數百個，但不是 SO 旨在回答的問題

這可以嗎？

它是否符合 OK 的標准？

連接到應用程序需要用戶名和密碼。 這些信息存儲在我的數據庫中的一個表中。 我正在考慮加密密碼字段。

密碼應始終以一種方式加密。 您采用用戶提供的內容，應用相同的一種方式加密並將結果與​​存儲的加密進行比較。 同樣的結果，用戶提供的密碼是好的

該應用程序可以分發給多個客戶端。 我正在考慮實現三個不同的數據庫（測試、接受和生產，可能也在不同的服務器中）並且對於每個客戶端，我將在數據庫中創建一個特定的模式，以便每個客戶端都有自己的對象。 這樣，來自不同客戶端的數據之間永遠不會發生交互。 問題是向新客戶端提供應用程序需要自定義所有內容（架構、表、過程、功能等），但我覺得這可能會導致維護問題，因為每個更改都必須應用於每個客戶端的架構。

我們無法回答，因為我們不知道您的目標市場對數據分離的需求。 大多數注冊服務的公司都可以與其他客戶共享數據庫，並且通過一些表內數據實現分離意味着“客戶有自己的完全隨機的GUID，然后所有帳戶都有一個clientid，所有的用戶有一個 accountid 等等。”所以數據和分離有明確的層次結構。

如果你只有少數客戶端並且他們要求與對等點高度分離，你可以考慮為每個客戶端創建一個新的數據庫（相同結構，不同數據），因為處理具有相同表的多個不同模式可能是一個噩夢

關於DB連接，雖然可以在App.Config中包含連接字符串，但在Visual Studio中，也可以直接連接DataSources中的DataBase

有，但您可能會發現您的連接字符串最終存儲在配置文件中。 運行應用程序的客戶端計算機上通常不存在 Visual Studio，因此在您發布時，它知道的對應用程序工作至關重要的任何內容都與應用程序捆綁在一起

最好的方法是什么？

不是一個問題，所以旨在回答，抱歉