Pros y contras de AppSettings vs ApplicationSettings (aplicación.NET.config / Web.config)

La configuración de la aplicación se puede controlar desde un diseñador (generalmente hay una Configuración.archivo de configuración por defecto) por lo que es más fácil de modificar y se puede acceder a ellos mediante programación a través de la clase de configuración donde aparecen como una propiedad fuertemente escrito. También puede tener configuraciones de nivel de aplicación y usuario, así como configuraciones predeterminadas para revertir.

Esto está disponible desde.NET 2.0 en adelante y desactiva la otra forma de hacerlo (por lo que puedo decir).

Más información se administra en: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

He estado usando un patrón que encontré hace un tiempo donde se usan etiquetas xml básicas pero se envuelven los ajustes en una clase de configuración estática. So-una aplicación de BRICOLAJE.Configuración.

DotNetPearls Static Config Pattern

Si lo haces de esta manera puedes:

• utilice diferentes conjuntos de valores de configuración para diferentes entornos (dev, test, prod)
• proporcionar valores predeterminados sensibles para cada configuración
• controla cómo se definen e instancian los valores

Es tedioso de configurar, pero funciona bien, oculta las referencias a los nombres de las claves y está fuertemente escrito. Este tipo de patrón funciona bien para la configuración que no se cambia por la aplicación, aunque probablemente podría trabajar en soporte para los cambios también.

Config:

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

Clase de configuración:

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

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        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
    }

Me gusta trabajar con la versión más simple para almacenar y acceder a valores individuales.

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

Escribí una clase de utilidad para acceder a los valores de forma segura que permite los valores predeterminados. Si no se proporcionan los valores predeterminados, se proporcionan mensajes de excepción útiles.

Puedes ver / descargar la clase aquí:

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

Para entender los pros y contras de los ajustes en el app.config, le sugiero que mire en los detalles técnicos de ambos. He incluido enlaces donde se puede encontrar el código fuente para el manejo, describiendo más detalles técnicos a continuación.

Permítanme resumir brevemente lo que reconocí cuando trabajé con ellos ( nota: lo mismo es aplicable al archivo web.config de un sitio web / aplicación web):

ApplicationSettings
(haga clic arriba para ver el código fuente y detalles técnicos)

Pros

• Permiten almacenar datos escritos, incluidos los tipos de objetos (a través de la propiedad serializeAs)

• Tienen un alcance de usuario y aplicación, lo que permite almacenar valores predeterminados

• Se admiten en la sección de configuración de Visual Studio

• Las cadenas largas y / o los datos con caracteres especiales están muy bien soportados (por ejemplo, cadenas JSON incrustadas con comillas dobles)

Contras

• La configuración del usuario se almacena en un lugar diferente en el perfil del usuario (con una ruta críptica), puede ser difícil de limpiar

• La configuración del ámbito de aplicación es de solo lectura durante el tiempo de ejecución de la aplicación (solo la configuración del ámbito de usuario se puede cambiar durante el tiempo de ejecución)

• Métodos de lectura / escritura código creado por el diseñador de configuraciones de Visual Studio, no proporcionado directamente por 3rd party herramientas (consulte el enlace anterior para obtener una solución alternativa)

AppSettings
(haga clic encima para ver el código fuente y los detalles técnicos)

Pros

• Son "ligeros", es decir, fáciles de manejar

• Acceso de lectura y escritura durante el tiempo de ejecución de la aplicación

• Pueden ser editados fácilmente por los administradores en el
  Administrador de Servicios de Información de Internet (IIS)
  ^{(Vista de características - > Configuración de la aplicación, tenga en cuenta que el nombre del icono es engañoso, ya que solo puede manejar AppSettings y no ApplicationSettings)}

Contras

• Admite solo datos de cadena; la longitud de la cadena y los caracteres especiales están limitados

• No tienen un alcance de usuario

• No admiten valores predeterminados

• No son compatibles directamente con Visual Studio sección de configuración