Pros y contras de AppSettings vs applicationSettings (.NET app.config / Web.config)


166

Al desarrollar una aplicación de formularios Windows Forms .NET tenemos la opción de elegir entre esas App.configetiquetas para almacenar nuestros valores de configuración. ¿Cuál es mejor?

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

En el código de ejemplo de MS, usan appSettings msdn.microsoft.com/en-us/library/… esto me parece confuso :(
Caza

Encontré este artículo codeproject.com/KB/files/… parece implicar que appSettings es para w / r y el applicationSettings es para solo lectura.
Caza

Otro artículo que es relevante stackoverflow.com/questions/453161/…
Hunt

Tenga en cuenta que lo mismo se aplica a web.config, por lo que agregué la etiqueta web.config a esta pregunta.
Matt

Respuestas:


151

Lo básico <appSettings>es más fácil de manejar: solo abofetear una <add key="...." value="..." />entrada y listo.

La desventaja es: no hay verificación de tipo, por ejemplo, no puede suponer con seguridad que su número que desea configurar realmente es un número: alguien podría poner una cadena en esa configuración ... simplemente tiene acceso a él ConfigurationManager["(key)"]y luego está arriba para que sepa con lo que está tratando.

Además, con el tiempo, <appSettings>puede volverse bastante complicado y desordenado, si muchas partes de su aplicación comienzan a poner cosas allí (¿recuerda el viejo archivo windows.ini? :-)).

Si puede, preferiría y recomendaría usar sus propias secciones de configuración: con .NET 2.0, se vuelve realmente fácil. De esa manera, puede:

  • a) Defina sus ajustes de configuración en código y haga que sean seguros y mecanografiados
  • b) Puede separar limpiamente SU configuración de la de los demás. ¡Y también puede reutilizar su código de configuración!

Hay una serie de artículos realmente buenos sobre usted para desmitificar el sistema de configuración .NET 2.0 en CodeProject:

  1. Desentrañar los misterios de la configuración de .NET 2.0

  2. Decodificando los misterios de la configuración de .NET 2.0

  3. Descifrando los misterios de la configuración de .NET 2.0

¡Muy recomendable! Jon Rista hizo un gran trabajo al explicar el sistema de configuración en .NET 2.0.


2
Creo que la configuración de la aplicación es más fácil de agregar, editar y eliminar configuraciones, además de que no tiene que escribir una línea de código, además de que son de tipo seguro, además de que puede aplicarlas al usuario o la aplicación, ya que solo puede usar la pestaña Configuración en el proyecto propiedades en VS.
markmnl

20

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

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

Se dan más detalles en: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx


14

He estado usando un patrón que encontré hace un tiempo en el que usas etiquetas xml básicas pero envuelves la configuración en una clase de configuración estática. Entonces, una aplicación de bricolaje.

Patrón de configuración estática DotNetPearls

Si lo haces de esta manera puedes:

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

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

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
    }

11

Para comprender los pros y los contras de la configuración en el app.config, le sugiero que examine los detalles técnicos de ambos. He incluido enlaces donde 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 se aplica al web.configarchivo de un sitio web / aplicación web):


Configuración de la aplicación en .NET
(haga clic arriba para ver el código fuente y los detalles técnicos)


Pros

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

  • 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 son muy compatibles (por ejemplo, cadenas JSON incrustadas que contienen 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 alcance de la aplicación es de solo lectura durante el tiempo de ejecución de la aplicación (solo se puede cambiar la configuración del alcance del usuario durante el tiempo de ejecución)

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


AppSettings en .NET
Update: AppSettings en .NET Core
(haga clic arriba 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.

  • Los administradores pueden editarlos fácilmente en el Administrador de
    Internet Information Services (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

  • Solo admite datos de cadena; la longitud de la cadena y los caracteres especiales son limitados

  • No tienen alcance de usuario

  • No admiten valores predeterminados

  • No se admiten directamente en la sección de configuración de Visual Studio



9

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 una manera segura de tipos que permite 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/


3
+1, es más simple, especialmente si tiene varios ensamblajes (la configuración generalmente tiene una sección por ensamblaje). Tengo una clase auxiliar similar. Por cierto, su clase actualmente espera que el archivo de configuración use cadenas sensibles a la cultura, lo que no es una buena cosa, por ejemplo, debe ser "Double. TryParse (s, NumberStyles.Any, CultureInfo.InvariantCulture, out result)" en lugar de "Double. TryParse ( s, resultado) ". Además, las pautas de codificación de MS recomiendan GetInt32, GetInt16, GetBoolean en lugar de GetInt, GetShort, GetBool.
Joe

Eso está bien, pero no responde la pregunta sobre los pros y los contras de AppSettings.
Matt

@ Matt, la ventaja es que es más simple. La desventaja es que es más simple. Si solo necesita un par de valores literales (bools, ints, string, etc.), este enfoque ofrece la mayor inversión. Si necesita datos estructurados, separación de espacios de nombres, validación / finalización compatible con XSD, etc., entonces una sección personalizada podría ser mejor. Otra opción es ignorar el App.configarchivo por completo y usar su propio archivo de configuración. Muchas bibliotecas hacen eso. NLog viene a la mente.
Drew Noakes

@DrewNoakes - Estoy de acuerdo contigo. Gracias por la aclaración.
Matt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.