AppSettings与applicationSettings的优缺点(.NET app.config/Web.config)

在开发.NET Windows窗体应用程序时,我们可以在这些App.config标记之间进行选择以存储配置值.哪一个更好？

  
  
    
  

  
  
    
        

    
  
  
    
      
        TABLEA
      
    
  

marc_s.. 145

基本更易于处理 - 只需打入一个条目就可以了.

缺点是:没有类型检查,例如,您无法安全地假设您想要配置的号码确实存在一个数字 - 有人可以将字符串放入该设置中......您只需访问它ConfigurationManager["(key)"]然后就可以了要知道你在处理什么.

此外,随着时间的推移,如果应用程序的很多部分开始将内容放入其中,那么可能会变得相当复杂和混乱(请记住旧的windows.ini文件？:-)).

如果可以,我宁愿并建议使用您自己的配置部分 - 使用.NET 2.0,它真的变得非常简单,这样,您可以:

a)在代码中定义配置设置,并使其类型安全并进行检查

b)您可以将您的设置与其他人的设置完全分开.而且你也可以重用你的配置代码!

有一系列非常好的文章可以揭开CodeProject上的.NET 2.0配置系统的神秘面纱:

揭开.NET 2.0配置的神秘面纱

解码.NET 2.0配置的奥秘

破解.NET 2.0配置的奥秘

强烈推荐!Jon Rista在.NET 2.0中解释配置系统方面表现出色.

1> marc_s..：

---

基本更易于处理 - 只需打入一个条目就可以了.

缺点是:没有类型检查,例如,您无法安全地假设您想要配置的号码确实存在一个数字 - 有人可以将字符串放入该设置中......您只需访问它ConfigurationManager["(key)"]然后就可以了要知道你在处理什么.

此外,随着时间的推移,如果应用程序的很多部分开始将内容放入其中,那么可能会变得相当复杂和混乱(请记住旧的windows.ini文件？:-)).

如果可以,我宁愿并建议使用您自己的配置部分 - 使用.NET 2.0,它真的变得非常简单,这样,您可以:

a)在代码中定义配置设置,并使其类型安全并进行检查

b)您可以将您的设置与其他人的设置完全分开.而且你也可以重用你的配置代码!

有一系列非常好的文章可以揭开CodeProject上的.NET 2.0配置系统的神秘面纱:

揭开.NET 2.0配置的神秘面纱

解码.NET 2.0配置的奥秘

破解.NET 2.0配置的奥秘

强烈推荐!Jon Rista在.NET 2.0中解释配置系统方面表现出色.

---

我找到的applicationSettings轻松地添加编辑和删除设置,再加上你不用写一行代码,再加上他们是类型安全的,再加上你可以范围他们的用户或应用程序,因为你可以用在项目的设置选项卡VS中的属性

2> Peter C..：

---

应用程序设置可以从设计器控制(默认情况下通常有一个Settings.settings文件),因此它更容易修改,您可以通过Settings类以编程方式访问它们,它们看起来像一个强类型属性.您还可以具有应用程序和用户级别设置,以及用于回滚的默认设置.

这可以从.NET 2.0开始提供,并且不赞成其他方式(据我所知).

更多细节见:msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

3> HAL9000..：

---

我一直在使用我发现的模式,你在那里使用基本的xml标签,但将设置包装在静态配置类中.所以 - 一个DIY App.Settings.

DotNetPearls静态配置模式

如果你这样做,你可以:

为不同的环境使用不同的配置值集(dev,test,prod)

为每个设置提供合理的默认值

控制如何定义和实例化值

设置但执行良好,隐藏对密钥名称的引用,并且是强类型的,这很繁琐.这种模式适用于未被应用程序更改的配置,尽管您也可以支持更改.

配置:

配置类:

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// 

        /// Initializes all settings when the app spins up
        /// 
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

4> Matt..：

---

要了解优点和缺点的设置app.config,我建议你看看双方的技术细节.我已经包含了链接,您可以在其中找到处理源代码,下面将介绍更多技术细节.

让我简要总结一下我在使用它们时所认识到的内容(注意:同样适用于web.config网站/ Web应用程序的文件):

---

applicationSettings
(点击上方查看源代码和技术细节)

优点

它们允许存储类型化数据,包括对象类型(通过serializeAs属性)

它们具有用户和应用程序范围,允许存储默认值

它们在Visual Studio的配置部分中受支持

支持长字符串和/或具有特殊字符的数据(例如,包含双引号的嵌入式JSON字符串)

缺点

用户设置存储在用户配置文件中的不同位置(具有神秘路径),可能难以清理

应用程序范围设置在应用程序运行期间是只读的(在运行时只能更改用户范围设置)

由Visual Studio的设置设计器构建的读/写方法代码,不是由第三方工具直接提供的(请参阅上面的链接以获取解决方案)

---

AppSettings
(点击上方查看源代码和技术细节)

优点

是"轻量",即易于处理

在应用程序的运行时期间进行读写访问

管理员可以在
Internet信息服务(IIS)管理器中 轻松编辑它们
^{(功能视图 - >应用程序设置,请注意,图标的名称具有误导性,因为它只能处理AppSettings而不能处理ApplicationSettings)}

缺点

仅支持字符串数据; 字符串长度和特殊字符是有限的

他们没有用户范围

它们不支持默认值

在Visual Studio的配置部分中不直接支持

---

5> Drew Noakes..：

---

我喜欢使用更简单的版本来存储和访问单个值.

我编写了一个实用程序类,以类型安全的方式访问值,允许使用默认值.如果未提供默认值,则会给出有用的异常消息.

你可以在这里看到/下载课程:

http://www.drewnoakes.com/code/util/app-settings-util/

---

+1,它更简单,特别是如果你有多个程序集(设置通常每个程序集有一个部分).我有一个类似的助手类.BTW你的班级目前希望配置文件使用对文化敏感的字符串,这不是一件好事 - 例如应该是"Double.TryParse(s,NumberStyles.Any,CultureInfo.InvariantCulture,out result)"而不是"Double.TryParse( s,结果)".同样对于nitpick,MS编码指南推荐GetInt32,GetInt16,GetBoolean而不是GetInt,GetShort,GetBool.