example - Pros y contras de AppSettings vs applicationSettings(.NET app.config/Web.config)
wcf endpoint configuration (5)
El <appSettings> básico es más fácil de manejar: simplemente ingrese una entrada <add key="...." value="..." /> y listo.
La desventaja es: no hay verificación de tipo, por ejemplo, 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 ConfigurationManager["(key)"] y luego depende de usted saber a qué se enfrenta.
Además, con el tiempo, las <appSettings> pueden volverse complicadas y complicadas, si muchas partes de tu aplicación comienzan a poner cosas allí (¿recuerdas el viejo archivo windows.ini? :-)).
Si puede, preferiría y recomendaría usar sus propias secciones de configuración: con .NET 2.0, se ha vuelto realmente fácil, de esta manera, usted puede:
- a) Defina las configuraciones de configuración en el código y haga que sean seguros y seguros
- b) Puedes separar limpiamente TU configuración de la de los demás. ¡Y también puedes reutilizar tu código de configuración!
Hay una serie de artículos realmente buenos sobre usted para desmitificar el sistema de configuración de .NET 2.0 en CodeProject:
¡Muy recomendable! Jon Rista hizo un gran trabajo al explicar el sistema de configuración en .NET 2.0.
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>
He estado utilizando un patrón que encontré hace un tiempo en el que usa etiquetas XML básicas pero ajusta las configuraciones en una clase de configuración estática. Entonces, una aplicación de bricolaje. Configuración.
Patrón de configuración estática de DotNetPearls
Si lo haces de esta manera, puedes:
- utilizar 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 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" />
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
}
La configuración de la aplicación se puede controlar desde un diseñador (normalmente hay un archivo Settings.settings de forma predeterminada) por lo que es más fácil de modificar y puede acceder a ellos mediante programación a través de la clase Settings 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.
Esto está disponible desde .NET 2.0 en adelante y desaprueba la otra forma de hacerlo (hasta donde yo sé).
Se brindan más detalles en: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx
Me gusta trabajar con la versión más simple para almacenar y acceder a valores únicos.
<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.
Puedes ver / descargar la clase aquí:
Para comprender los pros y los contras de las configuraciones en la app.config , le sugiero que investigue los detalles técnicos de ambas. 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 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 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 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 pueden cambiar las configuraciones 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
(haga clic arriba para ver el código fuente y 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 funciones -> 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
Soporta solo datos de cadena; la longitud de la cadena y los caracteres especiales son limitados
No tienen un alcance de usuario
No admiten valores predeterminados
No se admiten directamente en la sección de configuración de Visual Studio