【问题标题】:ConfigurationSettings vs Properties.SettingsConfigurationSettings 与 Properties.Settings
【发布时间】:2010-11-03 14:29:26
【问题描述】:

我有一个 Winform 应用程序,该应用程序当前存储在 DAL 项目Settings.settings 中的 16 个 SQL 连接。

我正在尝试编写一个“经理”类来简化这一点(like here)。但是,我在网上找到的大多数示例似乎都使用ConfigurationSettings.AppSettings["something"]。同时,我正在使用Properties.Settings.Default.something

请有人解释一下哪个被认为是正确的以及为什么对于桌面应用程序?

【问题讨论】:

    标签: c# .net sql configuration settings


    【解决方案1】:

    我认为正确的方法是使用app.config文件并将它们存储在connectionStrings部分?

    然后你可以像这样访问它们:

     ConfigurationManager.ConnectionStrings["something"].ConnectionString
    

    如果太“丑”,你可以轻松地写一个包装器。

    public class ConnectionManager
    {
        public string Something
        {
            get
            {
                 // TODO: check to make sure the configuration exists and throw an exception perhaps
                 return ConfigurationManager.ConnectionStrings["something"].ConnectionString;
            }
        }
    }
    

    糟糕...正如我所指出的,我的意思是执行 ConfigurationManager 而不是 ConfigurationSettings。

    【讨论】:

    • ConfigurationSettings.ConnectionStrings[] 是桌面的东西吗?我好像没找到。
    • @Refracted Paladin - 他指的是 ConfigurationManager - msdn.microsoft.com/en-us/library/…
    • @Joel Etherton:感谢您的澄清,这让他的回答更有意义。
    • 在.Net以前的版本中被命名为ConfigurationSettings
    【解决方案2】:

    我们更喜欢使用 Properties.Settings(又名 settings.settings),因为它是强类型的。不要尝试在同一个配置文件中使用具有不同环境(dev/prod)的花哨的技巧。每个环境都有一个单独的配置文件,并在部署它们时重命名配置要容易得多。即

    app.config 
    app.stage.config
    app.test.config
    app.prod.config
    

    我们使用PowerShell 脚本(类固醇上的批处理文件)进行部署。我将简化我们作为传统批处理文件所做的工作 - (伪代码/未经测试的示例):

    @echo off
    :: %1 is the environment name (first parameter)
    setlocal
    set source=c:\tfs\project\bin\release\
    set target=\\server\share\path\
    
    xcopy /s/e %source% %target%
    
    :: Using a copy command to rename/overwrite the env specific version
    if exists %target%\app.%1.config copy /y %target%\app.%1.config %target%\app.config
    

    【讨论】:

    • 您能否详细说明“...在部署时重命名配置...”听起来很有趣,但我现在还没有把这些点联系起来。
    • @Refracted Paladin:添加样本
    【解决方案3】:

    我从来都不喜欢将 sql 连接字符串放入软件的配置文件中。用户有出于好奇或愚蠢(或两者兼而有之)而愚弄他们的习惯。我喜欢将我的所有连接字符串(开发、模型、生产等)放入我的数据访问库的属性中,并在其中包含一个 ConfigurationSettings 类,我使用该类来根据消费方设置的某些属性来访问它们应用:

    public class ConfigurationSettings
    {
    
        public static string MyConnectionString
        {
        get
                if(ConfigurationSettings.TestMode)
                    return Properties.Settings.Default.MyConnectionStringTest;
                else
                    return Properties.Settings.Default.MyConnectionStringProd;
        }
        }
    
        // I typically only have test and not-test. This could
        // easily be some other combination of values to satisfy
        // multiple environments.
        public static bool TestMode { get; private set;}
    }
    

    这使我可以通过通用名称调用此类的静态属性,并根据某些条件使所有连接字符串可用。这让您的特定数据集、实体、您正在使用的任何数据模型都无需担心连接字符串,并且可以将设置编译到 .dll 中(不再需要担心它们)。也可以修改此方法,以类似的方法从 app.config(我为 ASP.Net 站点执行此操作)中提取设置。

    更新:确实没有您暗示的“正确”方式。 app.config 旨在保存无需重新构建应用程序即可修改的配置设置。属性设置旨在保存不可修改的设置。所以两者都是完全有效的。可能最“正确”的方式是对您的应用程序和开发团队都有意义的方式。

    【讨论】:

    • 为什么不使用预处理器#if DEBUG ... #endif 而不是布尔值?然后你不能忘记改变布尔值:)
    • @jgauffin - 这是在一个库中,它允许托管应用程序设置它是否是一个测试。它也不一定处于调试模式。它允许执行程序确定要运行的设置集。这真的归结为决定哪种方法最适合我们团队的方法,而这个方法胜出。
    【解决方案4】:

    Properties.Settings.Default 一般用于保存应用程序内部状态,如背景颜色,以记住用户设置。

    ConfigurationSettings 实际上是您所说的“管理器”类,可以从 app.config 文件访问其他自定义设置集,包括连接字符串。

    【讨论】:

      猜你喜欢
      • 2012-09-04
      • 2011-02-22
      • 1970-01-01
      • 1970-01-01
      • 2012-08-09
      • 1970-01-01
      • 1970-01-01
      • 2013-10-09
      • 1970-01-01
      相关资源
      最近更新 更多