Xml vs. Base de datos para la configuración de la aplicación

Question

La configuración de mi aplicación es muy jerárquica y se adapta muy bien a un solo XML. Pronto (YAGNI, Yeh) partes de esta información serán consumidas por otras aplicaciones de forma remota, lo que requiere una base de datos.

Así que comencé a diseñar tablas de bases de datos y a asignarlas a la jerarquía de clases de mi aplicación (usando EF). sin embargo, se convirtió en una pesadilla de mantenimiento.

Me encantaría saber de la experiencia de otros teniendo en cuenta este problema, gracias.

Answer 1

Tuvimos una muy buena experiencia almacenando la configuración en una base de datos para aplicaciones de larga ejecución (como sitios web y servicios). Ventajas:

• Puede editar la configuración remota y segura (usuario/contraseña)
• Es simple para la aplicación para recoger los cambios (select max(lmod) from config) de forma automática o por una señal (ping una página web o crear una archivo vacío en algún lugar)
• La aplicación solo necesita un único elemento de configuración por entorno (dev, test, prod): la base de datos a usar. Si tiene un servidor de aplicaciones, sus aplicaciones están libres de config para todos los entornos.

El problema principal es la edición si tiene una estructura de configuración jerárquica compleja con valores predeterminados, listas y herencia.Nuestras soluciones:

• La tabla de configuración consta de las siguientes filas: varchar de aplicación (32), varchar de claves (512), el valor varchar (4096)
• Una base de datos por medio ambiente (ordenador de desarrollo local, haciendo pruebas de desarrollo, prueba de integración , producción)
• La clave es jerárquica (option.suboption .... nombre)
• use valores predeterminados "opción. .name" (por ejemplo, "JDBC. .driver" ya que utilizamos un solo tipo de base de datos)
• Las listas se almacenan como cadenas, separadas por nueva línea.
• Los mapas se almacenan como cadenas, "nombre = valor \ n"
• Hay una implementación que puede leer la configuración desde un archivo (para pruebas unitarias). Asigne cada jerarquía de la clave a un elemento (......)

Los objetos de configuración ocultan estos detalles, por lo que la aplicación solo funciona con objetos.

Una clase especial es responsable de volver a leer la configuración en caso de un cambio. Por lo general, actualizamos la configuración en algún momento durante el día y un trabajo programado la volverá a cargar después de las horas. De esta forma, nunca necesitamos sincronizar los métodos de configuración.

La copia de seguridad y el historial de cambios fueron un problema. Lo arreglamos usando archivos XML en el VCS que luego se "cargan" en el DB. De esta forma, podríamos verificar la configuración de producción antes de cargarla (utilizándola con un conjunto especial de pruebas unitarias en una máquina desarrolladora). Cuando se activó durante la noche, por lo general funcionó de inmediato y el operador responsable de la aplicación simplemente tendría que hacer un poco de prueba.

Answer 2

La configuración de IMHO debe residir en archivos, los archivos funcionan bien para las personas y están bien para las computadoras. Los DB funcionan bien para big data, pero son excesivos para cosas humanas. Los dos son normalmente mutuamente exclusivos, y cuando intentas combinarlos obtienes algo así como el registro - uggh.

¿Por qué no dejar la configuración en un archivo y crear un DAL y una capa de servicio para que sus aplicaciones puedan usarla? Eso supone que puede alojar en un servidor central, si no tiene múltiples copias del archivo en la naturaleza.

Answer 3

Usar una base de datos (tal vez para almacenar este archivo config xml, si desea conservar el formato) tiene ventajas: puede registrar/auditar los cambios en la configuración y también realizar copias de seguridad y recuperación.

Básicamente su pregunta (la forma en que lo veo) mezcla dos cosas,

1. ¿Qué formato de la configuración debería ser en (XML, archivos ini, etc)
2. donde debe estar almacenado (planas archivo en el disco, columna de la tabla en la base de datos)

Puede almacenar fácilmente el archivo config xml en una base de datos y proporcionar una interfaz para editar/mostrar la información.

Answer 4

Los archivos de configuración deberían ser los más fáciles de manejar, así que colóquelos en los archivos. De esta forma, alguien puede hacer cambios allí incluso con el bloc de notas (si es necesario). La base de datos es realmente una exageración, a menos que desee que su configuración resida en algún servidor global y todas las instancias para compartirlo.