•  09-06-2019
  •  | 
  •  

题

我真的对 .Net v2 中 .Net 配置 dll、ASP.net 网站等的各种配置选项感到困惑 - 特别是在考虑配置文件在链的 UI/最终用户端的影响时。

因此，例如，我使用的一些应用程序使用我们访问的设置：

string blah = AppLib.Properties.Settings.Default.TemplatePath;

现在，这个选项看起来很酷，因为成员是强类型的，而且我无法输入 Visual Studio 2005 IDE 中不存在的属性名称。我们最终在命令行可执行项目的 App.Config 中得到这样的行：

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

（如果我们没有第二个设置，那么有人将调试 dll 发布到 live box 时可能会使用嵌入其中的调试连接字符串进行构建 - 哎呀）

我们还可以像这样访问设置：

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

现在，这些看起来很酷，因为我们可以从 dll 代码或 exe/aspx 代码访问设置，而我们在 Web 或 App.config 中需要的是：

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

但是，该值当然可能未在配置文件中设置，或者字符串名称可能输入错误，因此我们遇到了一系列不同的问题。

所以...如果我的理解是正确的，前一种方法提供了强类型，但在 dll 和其他项目之间共享值很差。后者提供了更好的共享，但打字能力较弱。

我觉得我一定错过了什么。目前，我什至不关心应用程序是否能够将值写回配置文件、加密或类似的内容。另外，我决定存储任何非连接字符串的最佳方法是在数据库中......然后我要做的下一件事就是存储电话号码给人们发短信，以防数据库连接问题，因此它们必须存储在数据库之外！

有帮助吗？

解决方案

Nij，我们思维的差异来自于我们的视角不同。我正在考虑开发主要使用 WinForms 客户端的企业应用程序。在本例中，业务逻辑包含在应用程序服务器上。每个客户端都需要知道要拨打的电话号码，但是如果该电话号码发生更改，将其放入每个客户端的 App.config 中就会出现问题。在这种情况下，将应用程序配置信息（或应用程序范围的设置）存储在数据库中并让每个客户端从那里读取设置似乎是显而易见的。

另一种 .NET 方式（我进行区分是因为在 .NET 出现之前，我们将应用程序设置存储在数据库表中）是将应用程序设置存储在 app.config 文件中，并通过生成的 Settings 类的方式进行访问。

我离题了。你的情况听起来不一样。如果所有不同的应用程序都在同一服务器上，您可以将设置放在更高级别的 web.config 中。但是，如果不是，您也可以拥有一个单独的“配置服务”，所有三个应用程序都可以通过该服务来获取其共享设置。至少在此解决方案中，您不会在三个位置复制代码，从而在添加设置时增加潜在的维护问题。不过听起来有点过度设计。

我个人偏好是使用强类型设置。实际上，我根据数据库中的设置表生成了自己的强类型设置类。这样我就可以两全其美。对我的设置和存储在数据库中的设置进行智能感知（注意：这是在没有应用程序服务器的情况下）。

我也有兴趣了解其他人的策略:)

其他提示

如果您使用 VS 2005+ 中的设置选项卡，则可以添加强类型设置并获取智能感知，如第一个示例中所示。

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

它物理存储在 App.Config 中。

您仍然可以使用配置文件的 appSettings 元素，甚至滚动您自己的 ConfigurationElementCollection、ConfigurationElement 和 ConfigurationSection 子类。

至于在非连接字符串的情况下存储设置、数据库或配置文件的位置：这取决于您的应用程序架构。如果您有一个由所有客户端共享的应用程序服务器，请在应用程序服务器上的 App.Config 中使用上述方法。否则，您可能必须使用数据库。将其放置在每个客户端上的 App.Config 中将导致版本控制/部署问题。

我认为您的困惑来自于这样一个事实：您的第一个示例看起来是一个自制的库，而不是 .NET 的一部分。配置管理器示例是内置功能的示例。

我支持罗布·格雷的回答，但想稍微补充一下。这可能过于明显，但如果您使用多个客户端，app.config 应存储特定于安装的所有设置，并且数据库应存储几乎所有其他内容。

单个客户端（或服务器）应用程序有些不同。这确实是更个人的选择。一个值得注意的例外是，如果设置是数据库中记录的 ID，在这种情况下，我将始终存储该设置 在 带有外键的数据库，以确保引用不会被删除。

是的 - 我认为我/我们正处于令人头痛的情况 Rob 描述 - 我们在三个独立服务器上有大约 5 或 6 个不同的网站和应用程序，需要访问相同的数据库。就目前情况而言，每个都有自己的 Web 或 App.config，其中包含我们主数据库访问 dll 库中描述的设置和/或覆盖设置。

Rob - 当你说应用程序服务器时，我不确定你的意思是什么？我能想到的最接近的事情是，我们至少可以通过将它们放在目录层次结构中更高的 web.config 中来在同一台计算机上的站点之间共享一些设置......但这也不是我能够调查的事情......认为了解强类型路线或弱类型路线中哪一个“更好”更重要。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top