从我有0经验的意义上来说，我是编程的新手：我从未开发过任何应用程序。几个月前，我开始使用WPF / C＃和SQL Server数据库开发桌面应用程序。
由于我对数据库更加熟悉，所以我要做的第一件事是创建数据库以及所有表和关系。我知道我不想在我的应用程序中包含查询，因此我创建了100多个存储过程，其中包含必须在我的应用程序中实现的所有逻辑。既然我已经完成了UI的创建，那么我将开始编码，我要做的第一件事就是在我的应用程序和数据库之间建立连接，并且我知道将连接字符串包括进来并不是一种好习惯，由于将来存在维护问题的风险，因此App.config中的DB用户/密码。
我认为最好的方法是在应用程序和数据库之间建立一层存储连接信息的层，以便我的应用程序可以与该层以及与数据库的层进行交互。我的问题是：我该怎么做？我在这里看到了建议创建WCF服务的答案。这对我来说就像一门外语，但我非常愿意学习。我想对具有零编程经验的人可以实现这样的体系结构还是应该放弃给出一些反馈。是否没有具有此类实现方式的开源文档？
第二，关于我的应用程序，我还应该注意其他最佳实践吗？例如：
我已经实现了RBAC方法，但是所有访问控制都在我的存储过程中实现。可以吗？
连接到该应用程序需要用户名和密码。这些信息存储在数据库的一个表中。我正在考虑加密密码字段。
该应用可以分发给多个客户端。我正在考虑实现三个不同的数据库（测试，接受和生产，也可能在不同的服务器中），并且对于每个客户端，我将在数据库中创建一个特定的架构，以便每个客户端都有自己的对象。这样，来自不同客户端的数据之间就不会存在交互。问题在于将应用程序提供给新客户端将需要自定义所有内容（模式，表，过程，功能等），但是我感觉这会引起维护问题，因为每次更改都必须在每个客户端的模式中应用。 / p>
重新建立DB连接，虽然可以在App.Config中包括连接字符串，但在Visual Studio中，还可以直接连接到DataSources中的数据库。最好的方法是什么？
我可能会错过其他事情，但是对这些问题有反馈会很棒。
答案 0 :(得分：1)
现在我已经完成创建UI
在阅读本文之前，我认为您已经完成了后端的创建
我知道，由于将来可能会出现维护问题，因此在App.config中包含连接字符串，数据库用户/密码不是一个好习惯。
如果您不打算将连接字符串存储在app.config中，则需要另一种身份验证方式，例如Windows凭据。或者您需要加密应用程序配置的各个部分。与其说是未来的维护，不如说是安全性。如果没有在您的app.config中添加数据库连接详细信息，将会造成更多的维护麻烦，因为在大多数情况下，事情都是经过设计的，以期这将成为现实。当然，您可以将它们存储在文本文件中，或者每次都向您的用户询问它们
我认为最好的方法是在应用程序和数据库之间建立一层存储连接信息的层，以便我的应用程序可以与该层以及与数据库的层进行交互。
与存储连接详细信息无关；这听起来像是您开始进入一种典型的体系结构，即具有一个处理数据库中对象的数据层和一个处理业务需要使用一个或多个数据层实体执行的操作的业务逻辑层。创建一个新帐户将需要有关人员和地址的信息，数据层可能会将它们视为不同的事物，而业务层将它们视为对特定流程至关重要的一件事。
我该怎么做？
大多数人通过将与数据有关的事情推迟到EF之类的库中来进行，该库对db及其包含的实体感兴趣，并在代码中对其进行建模。然后，您将拥有一组类来定义将要执行的操作实现业务目标，支持这些操作的一组数据存储类以及用于将业务对象映射到数据库实体对象的一组过程； UI生成一个CreateAccountModel并将其传递给AccountRepository的CreateAccount方法；在内部，帐户存储库通过db上下文了解数据库中的Person对象和Address对象，并将使用在CreateAccountModel中找到的数据来创建每个对象。这使创建帐户的业务需求过程与存储数据的事物断开了连接。从概念上讲，您可以将数据库换成另一个存储“个人和位置”而不是“人和地址”的数据库，而业务层不在乎。阅读有关该主题的内容；没有正确或错误的方法，因此提出基于事实的答案并非易事
我在这里看到了建议创建WCF服务的答案
WCF是Web服务的框架；计算机可以代替人类使用的网站。您可以肯定地插入此抽象层，但实际上，如果您的用户界面与数据存储和处理中心相距很远，或者您的企业财务模型依赖于您提供软件即服务，则只需要这样做即可。某人。我不希望在本地使用并且具有自己的数据库的UI会需要通过网络进行操作的复杂性，如果它要做的就是在本地计算机上调用服务
我应该放弃
这不是SO旨在回答的问题。经验丰富的专业人士不会问这个问题
是否没有具有此类实现方式的开源文档？
有数百万个项目和数以千计的架构；这应该告诉您，做某事的方法不止一种，最终正确的是主观/意见。如果它可以正常工作，并且不会崩溃并且满足客户的期望，并且您的构建和维护成本不会比您支付的价格高，那么您可以说这是正确的
第二，关于我的应用程序，我还应该注意其他最佳实践吗？
大概有数百个，但不是设计用来回答的问题
可以吗？
它符合合格标准吗？
连接到应用程序需要用户名和密码。这些信息存储在数据库的一个表中。我正在考虑加密密码字段。
密码应始终采用一种加密方式。您将得到用户给出的信息，以相同的一种方法应用加密，并将结果与存储的加密进行比较。结果相同，用户提供的密码很好
该应用可以分发给多个客户端。我正在考虑实现三个不同的数据库（测试，接受和生产，也可能在不同的服务器中），并且对于每个客户端，我将在数据库中创建一个特定的架构，以便每个客户端都有自己的对象。这样，来自不同客户端的数据之间就不会存在交互。问题在于将应用程序提供给新客户端将需要自定义所有内容（模式，表，过程，功能等），但是我感觉这会引起维护问题，因为每次更改都必须在每个客户端的模式中应用。 / p>
我们没有人可以回答，因为我们不知道目标市场对数据分离的需求。签署服务的大多数公司都可以与其他客户共享数据库，并可以通过一些表内数据方式实现分离，例如“客户拥有自己的完全随机的GUID，然后所有帐户都有一个clientid，所有用户有一个帐户ID等。”因此数据具有明确的层次结构和分隔。
如果您只有少数几个客户端，并且要求与同级客户端高度隔离，则可以考虑为每个客户端创建一个新的db（相同结构，不同数据），因为使用相同的多个不同架构进行处理桌子可能是一场噩梦
重新建立DB连接，虽然可以在App.Config中包含连接字符串，但在Visual Studio中，还可以直接连接到DataSources中的数据库
有，但是您可能会发现连接字符串最终还是存储在配置文件中。 Visual Studio通常不存在于运行该应用程序的客户端计算机上，因此在您发布该应用程序时，它所知道的对应用程序至关重要的所有内容都将与该应用程序捆绑在一起
什么是最好的方法？
不是一个问题，所以很想回答