¿Cómo centralizaría la configuración en varios proyectos?

Question

Tengo una solución con aproximadamente 10 proyectos con configuración de solo lectura. Son aplicaciones web, servicios de Windows, aplicaciones de consola, etc. Todos los proyectos, excepto uno, están en el mismo servidor. Cada proyecto tiene 3 entornos: desarrollo, prueba y producción. Entonces hay 30 conjuntos de configuraciones diferentes, cada uno con una cantidad decente de configuraciones. Es engorroso mantener la configuración constante en todas las aplicaciones y entornos.

Me he dado cuenta de que la mayoría de la configuración es común en cada proyecto, así que pensé que sería bueno centralizar la configuración de alguna manera. Leí en alguna parte que un servicio de WCF podría ser un buen enfoque. Pensé que tal vez una biblioteca que contiene una clase estática codificada podría funcionar bien, a pesar de tener que compilar para cambiar la configuración. Idealmente, la configuración debería provenir de un archivo .config real.

¿Cómo haría para centralizar la configuración para múltiples proyectos?

Answer 1

Si desea mantener la interfaz de configuración estándar, consulte el ProtectedConfigurationProvider. Este proveedor le permite almacenar sus datos de configuración exterior de un archivo de configuración estándar, cifrarlo como usted quiera, o redirigir las peticiones de configuración en cualquier forma que estimen conveniente:

• Redirecting Configuration with a Custom Provider - Wrox
• Implementing a Protected Configuration Provider - MSDN
• Protected Configuration - Blayd Software

La belleza de este enfoque es que nada cambia en sus aplicaciones existentes. No necesitan saber dónde se almacena su configuración. La recuperación de datos de configuración está aislada en el proveedor. Puede almacenarlo en un archivo central, almacenarlo en una base de datos o acceder a él a través de un servicio web. Si cambia de opinión, solo debe actualizar su proveedor. Todo lo demás se queda igual.

Answer 2

Sin duda podría configurar un servicio WCF que tiene una operación simple para recuperar la configuración, teniendo en cuenta la aplicación y el entorno como un parámetro; entonces podría hacer que el servicio cargue la configuración correcta de un archivo y devolverlo a la persona que llama. Puede ser una buena idea hacer archivos de configuración anidados, de modo que la configuración común solo se defina una vez en su nivel más genérico.

Un problema potencial podría surgir si el servicio WCF no funciona al iniciar una de sus aplicaciones; deberá decidir si hay configuración/almacenamiento en caché predeterminado de la copia anterior para esta situación, o si simplemente no lo hace Permitir que las aplicaciones se inicien si no pueden conectarse.

Otra cosa a tener en cuenta, sin embargo, es la ventaja de los archivos .config en .NET en que cuando cambian la aplicación puede responder; Es posible que desee tener un servicio de devolución de llamada WCF que notifique a los clientes si su configuración se ha actualizado en el servidor central, para que puedan solicitar una nueva copia y actualizarse si es necesario.

Answer 3

Dado que están (casi) todos en el mismo servidor, podría considerar proporcionar los valores predeterminados en los archivos machine.config y/o web.config centrales. Normalmente no soy partidario de utilizar/cambiar estos archivos, pero están ahí ... en \Windows\Micsrosoft.NET\Framework<version>\Config\