Question

我对.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>

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

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

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

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

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

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

所以...如果我的理解是正确的，那么前面的方法会给出强大的输入，但是在dll和其他项目之间分配不好的值。后者提供了更好的共享，但输入较弱。

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

Answer 1

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

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

它实际存储在App.Config中。

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

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

Answer 2

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

另一种，.NET方式，（我之所以区别，因为我们在.NET之前的日子里，在DB表中存储了应用程序设置）是将应用程序设置存储在app.config文件中并通过生成的设置类。

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

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

我也有兴趣为此学习其他人的策略：）

Answer 3

我认为你的困惑来自这样一个事实：你的第一个例子看起来像是一个家庭酿造的库，而不是.NET的一部分。配置管理器示例是内置功能的示例。

Answer 4

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

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

Answer 5

是的 - 我认为我/我们处于头痛状态Rob descibes - 我们在需要访问同一个数据库的三个独立服务器上有5个或6个不同的网站和应用程序。事实上，每个人都有自己的Web或App.config，其设置描述了设置和/或覆盖我们的主DB-access dll库中的设置。

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

了解.Net配置选项

5 个答案: