.Net 应用程序：数据库连接最佳实践

Question

我是编程初学者，因为我的经验是 0：我从未开发过任何应用程序。几个月前，我开始使用 SQL Server 数据库在 WPF/C# 中开发桌面应用程序。

随着我对数据库越来越熟悉，我做的第一件事就是创建我的数据库以及所有的表和关系。我知道我不想在我的应用程序中包含我的查询，所以我创建了 100 多个存储过程，其中包含必须在我的应用程序中实现的所有逻辑。现在我已经完成了我的 UI 的创建，我即将开始编码，我要做的第一件事是在我的应用程序和我的数据库之间建立一个连接，我知道包含我的连接字符串不是一个好习惯，由于未来维护问题的风险，App.config 中的数据库用户/密码。

我相信最好的办法是在我的应用程序和我的数据库之间有一个层，我可以在其中存储连接信息，以便我的应用程序可以与该层以及与数据库的层进行交互。我的问题是：我该怎么做？我在这里看到了建议创建 WCF 服务的答案。这对我来说就像一门外语，但我非常愿意学习。我想对编程经验为 0 的人是否可以实现这样的架构或我应该放弃一些反馈。有没有这种实现方式的开源文档？

其次，关于我的应用程序，我是否应该了解其他最佳做法？例如：

1. 我已经实现了 RBAC 方法，但所有访问控制都在我的存储过程中实现。可以吗？

2. 连接到应用程序需要用户名和密码。这些信息存储在我的数据库中的一个表中。我正在考虑加密密码字段。

3. 该应用程序可以分发给多个客户端。我正在考虑实现三个不同的数据库（测试、接受和生产，也可能在不同的服务器中），对于每个客户端，我将在数据库中创建一个特定的模式，以便每个客户端都有自己的对象。这样，来自不同客户端的数据之间就不会发生交互。问题是向新客户提供应用程序将需要自定义所有内容（模式、表、过程、功能......），但我觉得这可能会导致维护问题，因为每次更改都必须应用于每个客户的模式。

4. 关于 DB 连接，虽然可以在 App.Config 中包含连接字符串，但在 Visual Studio 中，也可以直接连接到 DataSources 中的数据库。最好的方法是什么？

我可能会错过其他一些事情，但如果能对这些问题提供反馈，那就太好了。

Answer 1

现在我已经完成了 UI 的创建

在阅读本文之前，我以为您已经完成了后端的创建

我知道在 App.config 中包含我的连接字符串、数据库用户/密码不是一个好习惯，因为存在未来维护问题的风险。

如果您不打算将连接字符串存储在 app.config 中，那么您需要另一种身份验证方式，例如 Windows 凭据。或者您需要加密应用程序配置的部分。它更多的是关于安全性而不是未来的维护。如果没有将数据库连接详细信息放入您的 app.config 中，则会造成更多的维护难题，因为大多数情况下，事情的设计都是为了期望它们会出现在那里。你可以将它们存储在一个文本文件中，或者每次都向你的用户询问它们，当然如果你愿意的话

我相信最好的办法是在我的应用程序和我的数据库之间建立一个层，我可以在其中存储连接信息，以便我的应用程序可以与该层以及与数据库的层进行交互。

与其说是存储连接详细信息，不如说是存储连接详细信息；这听起来像是您开始打破典型的架构，即拥有一个处理数据库中对象的数据层和一个处理业务需要使用一个或多个数据层实体执行的操作的业务逻辑层。创建新帐户需要有关人员和地址的信息，而数据层可能会将这些信息视为不同的事物，而业务层将它们视为对特定流程至关重要的事物

我该怎么做？

大多数人通过将与数据相关的事情推迟到像 EF 这样的库来做到这一点，该库对数据库及其包含的实体感兴趣并在代码中对其进行建模。然后你有一组类来定义你将执行的操作实现业务目标，以及一组支持这些操作的数据存储类，以及一组用于将业务对象映射到数据库实体对象的过程； CreateAccountModel 由 UI 生成并传递给 AccountRepository 的 CreateAccount 方法；在内部，帐户存储库通过 db 上下文了解数据库中的 Person 对象和 Address 对象，并将使用它在 CreateAccountModel 中找到的数据创建每个对象。这将创建帐户的业务需求过程与存储数据的事物断开。从概念上讲，您可以将数据库换成另一个存储个人和位置而不是个人和地址的数据库，而业务层并不关心。阅读有关该主题的信息；没有正确或错误的方法，因此提出基于事实的答案并不是一个容易的问题

我在这里看到了建议创建 WCF 服务的答案

WCF 是 Web 服务的框架；计算机可以代替人类使用的网站。您可以肯定地插入这一抽象层，但实际上，如果您的用户界面与数据存储和处理中心相距甚远，或者您的业务财务模型依赖于您将软件作为服务提供给某人。我不希望在本地使用并拥有自己的数据库的 UI 需要通过网络操作的复杂性，如果它所做的只是调用本地机器上的服务

我应该放弃吗

这不是一个 SO 旨在回答的问题。这不是经验丰富的专业人士会问的问题

是否没有具有此类实现的开源文档？

有数百万个项目和数千个架构；这应该告诉您，做某事的方式不止一种，最终正确的是主观/意见。如果它有效，并且不会崩溃并且满足客户的期望，并且构建和维护的成本没有超过您获得的报酬，那么您可以说它是正确的

其次，关于我的应用程序，我是否应该了解其他最佳做法？

可能有数百个，但不是 SO 旨在回答的问题

这样好吗？

它是否符合正常的标准？

连接到应用程序需要用户名和密码。这些信息存储在我的数据库中的一个表中。我正在考虑加密密码字段。

密码应该始终是一种加密方式。您获取用户提供的内容，应用相同的一种方式加密并将结果与​​存储的加密进行比较。同样的结果，用户提供的密码是好的

该应用可以分发给多个客户端。我正在考虑实现三个不同的数据库（测试、接受和生产，也可能在不同的服务器中），对于每个客户端，我将在数据库中创建一个特定的模式，以便每个客户端都有自己的对象。这样，来自不同客户端的数据之间就不会发生交互。问题是向新客户提供应用程序将需要自定义所有内容（模式、表、过程、功能......），但我觉得这可能会导致维护问题，因为每次更改都必须应用于每个客户的模式。

我们无法回答，因为我们不知道您的目标市场对数据分离的需求。大多数注册服务的公司都可以与其他客户共享数据库，并通过一些表内数据实现分离，例如“客户有自己的完全随机的 GUID，然后所有帐户都有一个 clientid，所有用户有一个帐户 ID 等。”因此数据有明确的层次结构和分离。

如果您只有少数客户，并且他们要求与同行高度分离，您可以考虑为每个客户创建一个新的数据库（相同的结构，不同的数据），因为处理具有相同的多个不同架构桌子可能是一场噩梦

关于数据库连接，虽然可以在 App.Config 中包含连接字符串，但在 Visual Studio 中，也可以直接连接到 DataSources 中的数据库

有，但您可能会发现您的连接字符串最终还是存储在配置文件中。 Visual Studio 通常不存在于运行应用程序的客户端计算机上，因此它所知道的对应用程序运行至关重要的任何内容都会在您发布时与应用程序捆绑在一起

最好的方法是什么？

这不是一个旨在回答的问题，抱歉