5

我对 .Net v2 中 dll、ASP.net 网站等的 .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>

（如果我们没有第二个设置，那么有人向 live box 发布调试 dll 可能已经构建了其中嵌入的调试连接字符串 - eek）

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

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

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

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

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

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

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

4

5 回答 5

3

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

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

这物理存储在 App.Config 中。

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

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

于 2008-09-12T00:06:23.457 回答
2

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

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

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

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

我也有兴趣学习其他人的策略:)

于 2008-09-12T02:37:10.723 回答
0

我认为您的困惑来自这样一个事实，即您的第一个示例看起来像是一个自制的库，而不是 .NET 的一部分。configurationmanager 示例是内置功能的示例。

于 2008-09-11T23:50:13.340 回答
0

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

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

于 2008-09-12T00:20:00.273 回答
0

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

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

于 2008-09-12T00:39:10.677 回答