Mejores prácticas en las configuraciones de configuración

Question

Me pregunto cuáles son las mejores prácticas para almacenar las configuraciones. Supongamos que tiene algunas configuraciones compartidas en varias aplicaciones. He escuchado formas buenas y malas de almacenar estos tipos de configuraciones que deben compartirse (archivos XML).

Solo me pregunto qué es un buen estándar en términos de mantenimiento de la configuración de la aplicación en las construcciones para una implementación más sencilla.

Creo que estoy mirando esto desde 2 escenarios:

1. Una aplicación interna (si se trata de un gran .com o pequeña aplicación de administración).
2. Al crear una API para que otros la consuman, cómo hacer referencia a la configuración cuando no se conocen los valores finales del consumidor que utilizará su API en su aplicación.

---

Agregado-1:

Gracias. He escuchado historias de terror en las que algunos lugares tienen la habilidad de administrar las configuraciones de configuración en múltiples aplicaciones. No soy un creador, así que no sé por qué, pero definitivamente quiero asegurarme de que lo entiendo ahora en términos de web.config vs. archivos de configuración personalizados, etc. tipo de escenarios.

Agregado-2:

Y qué pasa cuando se está creando una API para ser consumido. Usted tiene que decir una clase que va a extraer cierta información de configuración, pero esos puntos finales (propiedades) no están definidos hasta que el cliente consume su API (específicamente C# /. NET)? ¿Dónde y cómo establecería esas propiedades, digamos una clase de configuración que cree, como "ApplicationDefinitions"?

Answer 1

Si se trata de varias aplicaciones, puede (muy cuidadosamente) poner la configuración en machine.config.

O puede tener un archivo de configuración de configuración común separado que se lee y se utiliza para generar un nuevo web.config cada vez que crea su aplicación/solución web.

Answer 2

Lo que trato de hacer es separar los ajustes de configuración que serán diferentes para los despliegues a diferentes entornos en archivos separados, organizados por funciones lógicas, y luego no incluye estos archivos en los scripts de implementación ...

Si está codificando en .Net, luego las configuraciones que son comunes en múltiples aplicaciones se pueden almacenar en machine.config ... otra vez, no las ponga directamente en machine.config, sino que cree una referencia a un archivo separado (usando un atributo configSection y configSource = "" definido a medida, para crear una referencia indirecta a ese archivo separado ...

Answer 3

Tenemos que admitir varias pruebas de aceptación de usuario (UAT), producción, desarrollo entornos de recuperación de desastres y desastres

Lo ideal sería que esta información podría estar todos en un servidor LDAP gigante ..

En el mundo real que hemos escrito una tarea ANT que utiliza Yakarta-Velocidad como un motor de plantillas. Esto genera múltiples archivos (UAT, DEV, PROD, DR) desde un solo archivo de plantilla.

Tenemos un archivo central que se utiliza para todas las cosas comunes y archivos más pequeños para aplicaciones individuales. La línea de comando para cualquier aplicación necesita saber si se está ejecutando un sistema UAT/DEV .., etc. luego se carga en el archivo común y en el archivo específico de la aplicación.

Esto funciona muy bien en la práctica y lo hemos usado durante aproximadamente 8 años. He visto a muchas otras personas tratando de hacer malabarismos con múltiples archivos de aplicaciones para todos sus entornos y NO es bonito. Los errores a menudo se hacen.