Deployments, web.config’s y archivos de settings.

Quien no se han encontrado con web.config’s que contienen una cantidad de appSettings que es inmanejable. Supongo que más o menos todos, ya que si no se tiene cuidado, estas appSettings pueden crecer de manera desmesurada complicando mucho los deployments y sobre todo haciendo que las susodichas settings pierdan su efectividad ya que se puede dar el caso de no saber para que se usa cada una (sobre todo si el proyecto lo tienes en producción desde hace n años).

El nodo appSettings, es muy útil ya que nos permite modificar valores que afectan al comportamiento de nuestra aplicación de una forma rápida y efectiva (y sin ser necesario compilar), pero estas como todo, hay que mantenerlas y sobre todo organizarlas.

Con asp.net 2.0, se introdujeron unos nuevos ficheros que nos permitían manejar la configuración de nuestra aplicación de una forma mucho más ordenada y efectiva.

Estos ficheros, eran los ficheros de settings, por medio de ellos, vamos a poder almacenar app settings y acceder a ellas de una forma enumerada. Además cuando creamos un fichero de settings, se genera una clase que nos va a serializar y deserializar de una forma automática y optima el acceso a nuestras settings.

Para crear un fichero de settings, puedes hacerlo de dos formas:

  • Btn derecho en nuestro proyecto -> Add ítem -> settings file  (en class libraries)
  • Btn derecho en nuestro proyecto -> properties -> settings (en proyectos web)

Una vez que tenemos el archivo creado, ya solo nos queda añadir nuestras settings, el tipo de dato que va a almacenar, el scope (user o application) y por último el valor que almacenan.

Estas settings, al igual que las appSettings, se almacenan en nuestro web.config o app.config, de esta forma, también las podemos modificar sin tener que volver a compilar nuestro proyecto.

Veamos un ejemplo, supongamos que trabajamos con las appSettings, yo defino n appSettings en mi proyecto, y para usarlas debería hacer algo por el estilo a esto:
private const string NUMBER_OF_ITEMS = "NumberOfItems";
public int NumberOfItems
{
get{ return Convert.ToInt32(WebConfigurationManager.AppSettings[NUMBER_OF_ITEMS]); }
}

Si utilizamos un archivo de settings, únicamente tendríamos que hacer lo siguiente:

Settings.DisplaySettings.Default.NumberOfITems;

Siendo Settings el namespace y UrlSettings, la clase que se va a generar para poder encapsular el acceso a la susodichas settings.
Si esto ya os ha gustado (que seguro que sí), lo mejor viene ahora, si trabajamos con nuestro nodo de appSettings, las settings las tenemos que definir más o menos de la siguiente forma:

Mientras que si trabajamos con este tipo de ficheros y aunque igualmente se almacenan en el web.config, se almacenan de la siguiente forma:


<TestSettings.Settings.AppGlobalSettings>

date

Como podéis ver mucho más ordenado y eficiente.

Como apunte deciros que la buena práctica recomienda el incluir estas settings y nodos en nuestro web.config o app.config principal, pero si no lo hacéis, esta clase que se autogenera al no encontrar el valor buscado, usa el valor que se le dio cuando se precompiló. Que esto sea una ventaja o inconveniente lo tiene que decidir cada uno, el hecho es que el asunto funciona así.

Recientemente, he implementado una aplicación Web. Esta app explota las API’s de varias redes sociales. Para almacenar la configuración necesaria de cada una de estas piezas he usado este tipo de archivos. Permiten trabajar de forma muy sencilla y todo queda más claro y ordenado cuando vas a hacer el deployment. Además, mejora muchísimo la matenibilidad y administración del software desarrollado y desplegado.

 

Anuncio publicitario