2008-09-11 79 views
5

我对.Net v2的.Net配置的.Net配置的各种配置选项感到困惑 - 特别是在考虑配置文件在UI /端的影响时链的用户端。帮助了解.Net配置选项

因此,例如,一些应用程序的我,使我们与访问使用设置工作:

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

现在,这个选择似乎冷静,因为成员是stongly类型的,我不能键入Visual Studio 2005 IDE中不存在的属性名称。我们最终在一个命令行可执行项目的App.Config中这样的台词:

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

(如果我们没有第二个设定,有人释放一个DLL调试到直播盒可能已经建立其中嵌入调试连接字符串 - 克朗)

我们也有这样的访问设置:

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

现在,这些似乎很酷,因为我们可以从DLL的代码访问该设置,或EXE/aspx代码,以及我们在Web或App.config中需要的全部内容是:

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

但是,当然值可能不会在配置文件中设置,或者字符串名称可能错误输入,所以我们有一组不同的问题。

因此......如果我的理解是正确的,前面的方法给出了强大的输入,但dll和其他项目之间的值分享不好。后者提供更好的共享,但打字更弱。

我觉得我必须错过一些东西。目前,我甚至不关心应用程序能够将值写回配置文件,加密或类似的东西。另外,我决定存储任何非连接字符串的最佳方式是在数据库中......然后,我必须做的下一件事是在数据库连接问题的情况下将电话号码存储到文本人员,所以他们必须存储在数据库之外!

回答

2

Nij,我们在思维上的差异来自我们不同的观点。我正在考虑开发主要使用WinForms客户端的企业应用程序。在这种情况下,业务逻辑包含在应用程序服务器上。每个客户端都需要知道要拨打的电话号码,但如果该电话号码发生更改,则将其置于每个客户端的App.config中会出现问题。在这种情况下,将应用程序配置信息(或应用程序范围设置)存储在数据库中似乎很明显,并让每个客户端都从中读取设置。另一种.NET方式(我之所以这样区分,是因为我们已经在.NET .NET以前的版本中将存储的应用程序设置存储在数据库表中)是将应用程序设置存储在app.config文件中,并通过生成的设置类。

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

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

我对此感兴趣了解其他人的策略:)

+0

@rob_g迟来的感谢和'接受的答案'为您的评论在这里。我最终创建了一个设置数据库表,每行一行。我认为我没有达到'完美的解决方案',但比以前好很多。 – Nij 2010-03-05 21:19:15

0

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

3

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

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber; 

这实际上存储在App.Config中。

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

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

0

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

单个客户端(或服务器)应用程序有所不同。这真的是更多的个人选择。一个明显的例外是,如果该设置是数据库中的记录的ID,在这种情况下,我总是将设置存储在数据库与外键,以确保引用不会被删除。

0

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

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