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

Question

Al desarrollar una aplicación .NET Windows Forms, tenemos la opción entre esas etiquetas App.config 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> 

Answer 1

El <appSettings> básica es más fácil de tratar - sólo una palmada en una entrada <add key="...." value="..." /> y ya está.

El inconveniente es: no hay verificación de tipo, p. no puede suponer con seguridad que su número que quería configurar realmente es un número: alguien podría poner una cadena en esa configuración ... simplemente acceda a ella como ConfigurationManager["(key)"] y luego le toca a usted saber con qué está tratando .

Además, con el tiempo, la <appSettings> puede llegar a ser muy complicado y desordenado, si una gran cantidad de partes de su aplicación para empezar a poner cosas allí (recuerda el archivo Windows.ini edad? :-)).

Si se puede, yo preferiría y recomendar el uso de sus propias secciones de configuración - con .NET 2.0, que es realmente llegar a ser bastante fácil, de esa manera, se puede:

• a) Definir los parámetros de configuración de código y han de tipo seguro y controlado ellas
• b) se pueden separar limpiamente SUS configuración de todos otro. ¡Y también puedes reutilizar tu código de configuración!

Hay una serie de muy buenos artículos sobre la que desmitificar el sistema de configuración de .NET 2.0 en CodeProject:

1. Unraveling the mysteries of .NET 2.0 configuration

2. Decoding the mysteries of .NET 2.0 configuration

3. Cracking the mysteries of .NET 2.0 configuration

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

Answer 2

configuración de la aplicación se pueden controlar desde un diseñador (por lo general hay un archivo Settings.settings 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 en la que aparecen como una propiedad fuertemente tipado . También puede tener configuraciones de aplicación y nivel de usuario, así como configuraciones predeterminadas para retroceder.

Esto está disponible desde .NET 2.0 en adelante y desaprueba la otra forma de hacerlo (por lo que yo sé).

Más detalle se da en: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Answer 3

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 que permite valores predeterminados. Si no se proporcionan los valores predeterminados, se proporcionan mensajes de excepción útiles.

se puede ver/descargar la clase aquí:

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

Answer 4

He estado usando un patrón que encontré hace un tiempo en el que utiliza etiquetas XML básicas pero envolver los ajustes de configuración en una clase estática. Entonces, una aplicación de bricolaje. Configuración.

DotNetPearls Static Config Pattern

Si lo haces de esta manera se puede:

• uso de diferentes conjuntos de valores de configuración para diferentes entornos (dev, test, prod)
• proporcionar a los valores iniciales adecuados para cada ajuste
• control de cómo los valores se definen y crean instancias

Es tedioso configurar pero funciona bien, oculta las referencias a los nombres de las teclas y está fuertemente tipado. Este tipo de patrón funciona bien para la configuración que la aplicación no cambia, aunque probablemente también podría trabajar como 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" /> 

Config clase:

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 
    } 

Answer 5

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

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

---

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

Pros

• permiten almacenar datos mecanografiados, incluyendo los tipos de objetos (vía serializeAs propiedad)

• tienen un ámbito de usuario y la aplicación, lo que permite a los valores por defecto del almacén

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

• Las cadenas largas y/o los datos con caracteres especiales son muy compatibles (por ejemplo, cadenas JSON incrustadas que contienen doble comillas)

Contras

• configuración de usuario se almacenan en un lugar diferente en el perfil de usuario (con una ruta críptica), pueden ser difíciles 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 la configuración del alcance del usuario se puede cambiar durante el tiempo de ejecución)

• métodos de lectura/escritura de código integrado por el diseñador de configuración de Visual Studio, no proporcionada directamente por 3 ª Parte herramientas (ver enlace anterior para una solución de solución)

---

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

Pros

• Son "ligeros", es decirfáciles de manejar

• de lectura y escritura en tiempo de ejecución de la aplicación

• Ellos pueden ser fácilmente editadas por los administradores de los
  Internet Information Services (IIS)
  ^{(características Ver -> Configuración de la aplicación , tenga en cuenta que el nombre del icono es engañoso, ya que sólo puede manejar AppSettings y no ApplicationSettings)}

Contras

• Soporte de datos de cadena única; longitud de la cadena y caracteres especiales se limitan

• No tienen un ámbito de usuario

• Ellos no son compatibles con los valores por defecto

• no son compatibles directamente en la sección de configuración de Visual Studio

---