Archivos de configuración de la aplicación [cerrado]

StackOverflow https://stackoverflow.com/questions/12144

Pregunta

Bien, no quiero comenzar una guerra santa aquí, pero estamos en el proceso de intentar consolidar la forma en que manejamos los archivos de configuración de nuestras aplicaciones y estamos luchando por tomar una decisión sobre el mejor enfoque a seguir. .Por el momento, cada aplicación que distribuimos utiliza sus propios archivos de configuración ad-hoc, ya sean archivos de propiedades (estilo ini), XML o JSON (¡uso interno solo por el momento!).

La mayor parte de nuestro código es Java en este momento, por lo que hemos estado analizando Configuración de Apache Commons, pero hemos descubierto que es bastante detallado.También hemos mirado Frijoles XML, pero parece que hay muchas tonterías.También siento que me están empujando hacia XML como formato, pero mis clientes y colegas tienen miedo de probar otra cosa.Puedo entenderlo desde la perspectiva del cliente, todo el mundo ha oído hablar de XML, pero al final del día, ¿no deberíamos utilizar la herramienta adecuada para el trabajo?

¿Qué formatos y bibliotecas utiliza la gente en los sistemas de producción hoy en día? ¿Alguien más está tratando de evitarlos? impuesto por tramos angulares?

Editar: realmente necesita ser una solución multiplataforma:Linux, Windows, Solaris, etc.y la elección de la biblioteca utilizada para interactuar con los archivos de configuración es tan importante como la elección del formato.

¿Fue útil?

Solución

XML XML XML XML.Estaban Hablando archivos de configuración aquí.No existe un "impuesto entre corchetes angulares" si no estás serializando objetos en una situación de alto rendimiento.

Los archivos de configuración deben ser legibles y comprensibles para los humanos, además de legibles para las máquinas.XML es un buen compromiso entre los dos.

Si en su tienda hay gente que tiene miedo de esa novedosa tecnología XML, me siento mal por usted.

Otros consejos

YAML, por la sencilla razón de que genera archivos de configuración muy legibles en comparación con XML.

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

Los ejemplos fueron tomados de esta página: http://www.kuro5hin.org/story/2004/10/29/14225/062

Primero:Este es un tema de debate realmente grande, no una sesión rápida de preguntas y respuestas.

Mi favorito en este momento es simplemente incluir lua, porque

  • Puedo permitir cosas como ancho=alto*(1+1/3)
  • Puedo hacer que funciones personalizadas estén disponibles
  • Puedo prohibir cualquier otra cosa.(imposible en, por ejemplo, Python (incluidos los pepinillos))
  • De todos modos, probablemente querré un lenguaje de secuencias de comandos en otra parte del proyecto.

Otra opción, si hay muchos datos, es utilizar sqlite3, porque tienen razón al afirmar

  • Pequeño.
  • Rápido.
  • Confiable.

Elija tres.

A lo que me gustaría agregar:

  • las copias de seguridad son muy sencillas.(simplemente copie el archivo db.)
  • Es más fácil cambiar a otra base de datos, ODBC, lo que sea.(que es de archivo feo)

Pero nuevamente, este es un problema mayor.Una "gran" respuesta a esto probablemente implique algún tipo de matriz de características o lista de situaciones como:

Cantidad de datos o tiempo de ejecución corto

  • Para grandes cantidades de datos, es posible que desee un almacenamiento eficiente, como una base de datos.
  • Para tiradas cortas (a menudo), es posible que desee algo para lo que no necesite realizar muchos análisis, considere algo que se pueda mapear directamente.

¿A qué se refiere la configuración?

  • Anfitrión:
    • Me gusta YAML en/etc.¿Está eso reimplementado en Windows?
  • Usuario:
    • ¿Permite a los usuarios editar la configuración con el editor de texto?
    • ¿Debería ser gestionable de forma centralizada?¿Registro/gconf/base de datos remota?
    • Que el usuario tenga varios diferentes perfiles?
  • Proyecto:
    • ¿Archivo(s) en el directorio del proyecto?(El control de versiones suele seguir este modelo...)

Complejidad

  • ¿Hay sólo unos pocos valores fijos?Considere YAML.
  • ¿Los datos están anidados o son dependientes de alguna manera?(Aquí es donde se pone interesante.)
  • ¿Podría ser una característica deseable permitir alguna forma de secuencias de comandos?
  • Las plantillas pueden verse como una especie de archivos de configuración.

Sin iniciar una nueva guerra santa, los sentimientos de la publicación del 'impuesto al tramo angular' es un área en la que muy en desacuerdo con Jeff.XML no tiene nada de malo, es razonablemente legible por humanos (tanto como lo son los archivos YAML, JSON o INI), pero recuerde que su intención es que las máquinas lo lean.La mayoría de las combinaciones de lenguaje/marco vienen con algún tipo de analizador XML gratuito, lo que hace que XML sea una muy buena opción.

Además, si está utilizando un buen IDE como Visual Studio, y si el XML viene con un esquema, puede pasar el esquema a VS y mágicamente obtendrá intellisense (puede obtener uno para NHibernate, por ejemplo).

En última instancia, debe pensar con qué frecuencia tocará estos archivos una vez en producción, probablemente no con tanta frecuencia.

Esto todavía lo dice todo sobre XML y por qué sigue siendo una opción válida para archivos de configuración (desde Tim Bray):

"Si quieres proporcionar datos de propósito general con los que el receptor podría querer hacer cosas extrañas y locas imprevistas, o si quieres ser realmente paranoico y quisquilloso con i18n, o si lo que estás enviando se parece más a un documento que a una estructura, o si el orden de los datos es importante, o si los datos son potencialmente de larga duración (más de segundos), XML es el camino a seguir.También me parece que la combinación de XML y XPath da en el clavo para los formatos de datos que necesitan ser extensibles;es decir, es bastante fácil escribir código de procesamiento XML que no fallará ante la presencia de cambios en el formato del mensaje que no afecten a la parte que le interesa".

@Chico

Pero la configuración de la aplicación no siempre es solo pares clave/valor.Mire algo como la configuración de Tomcat para saber en qué puertos escucha.He aquí un ejemplo:

    <Connector port="80" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />


    <Connector port="8009" 
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

Puede tener cualquier número de conectores.Defina más en el archivo y existirán más conectores.No definas más y ya no exista.No hay una buena manera (en mi humilde opinión) de hacer eso con pares clave/valor antiguos y simples.

Si la configuración de su aplicación es simple, entonces algo simple como un archivo INI que se lee en un diccionario probablemente esté bien.Pero para algo más complejo como la configuración del servidor, sería muy complicado mantener un archivo INI, y algo más estructural como XML o YAML sería mejor.Todo depende del problema planteado.

Estamos utilizando archivos de configuración de estilo ini.Usamos el nini biblioteca para gestionarlos.Nini lo hace muy fácil de usar.Nini fue originalmente para .NET pero se ha portado a otras plataformas usando Mono.

XML, JSON, INI.
Todos tienen sus fortalezas y debilidades.
En el contexto de una aplicación, creo que la capa de abstracción es lo importante.
Si puede elegir una forma de estructurar los datos que sea un buen término medio entre la legibilidad humana y cómo desea acceder/abstraer los datos en el código, está en lo cierto.

Donde trabajo usamos principalmente XML, y realmente no puedo creer que un archivo de configuración cargado en un caché como objetos cuando se lee por primera vez o después de escribirlo, y luego se abstrae del resto del programa, realmente sea una gran parte de un éxito ni en la CPU ni en el espacio en disco.
Y también es bastante legible, siempre que estructures el archivo correctamente.

Y todos los lenguajes en todas las plataformas admiten XML a través de algunas bibliotecas bastante comunes.

@Herms

Lo que realmente quise decir fue seguir la forma recomendada en que el software debe almacenar los valores de configuración para cualquier plataforma determinada.

Lo que a menudo obtienes también son las formas recomendadas en que estos deben o pueden modificarse.Como un menú de configuración en un programa o un panel de configuración en una aplicación de "preferencias del sistema" (por ejemplo, para software de servicios del sistema).No permitir que los usuarios finales los modifiquen directamente a través de RegEdit o NotePad...

¿Por qué?

  1. Los usuarios finales (=clientes) están acostumbrados a sus plataformas.
  2. El sistema de copias de seguridad puede guardar mejor las "configuraciones seguras", etc.

@nuevelados

Acerca de " elección de biblioteca ", intente vincular (enlace estático) cualquier biblioteca seleccionada para reducir el riesgo de entrar en una guerra de conflictos de versiones en las máquinas de los usuarios finales.

Si su archivo de configuración es de escritura única, de solo lectura al arrancar y sus datos son un conjunto de pares de nombre y valor, su mejor opción es aquella que su desarrollador pueda hacer trabajar primero.

Si sus datos son un poco más complicados, con anidamiento, etc., probablemente esté mejor con YAML, XML o SQLite.

Si necesita datos anidados y/o la capacidad de consultar los datos de configuración después del inicio, utilice XML o SQLite.Ambos tienen lenguajes de consulta bastante buenos (XPATH y SQL) para datos estructurados/anidados.

Si sus datos de configuración están altamente normalizados (p. ej.Quinta forma normal) estará mejor con SQLite porque SQL es mejor para manejar datos altamente normalizados.

Si planea escribir en el conjunto de datos de configuración durante la operación del programa, entonces será mejor que utilice SQLite.Por ejemplo, si está descargando datos de configuración desde otra computadora, o si está basando decisiones futuras de ejecución de programas en datos recopilados en ejecuciones anteriores de programas.SQLite implementa un motor de almacenamiento de datos muy robusto que es extremadamente difícil de corromper cuando hay cortes de energía o programas que se cuelgan en un estado inconsistente debido a errores.Los datos corruptibles generan altos costos de soporte de campo, y SQLite funcionará mucho mejor que cualquier solución local o incluso bibliotecas populares en torno a XML o YAML.

Mira mi pagina para obtener más información sobre SQLite.

Hasta donde yo sé, el registro de Windows ya no es la forma preferida de almacenar la configuración si utiliza .NET; la mayoría de las aplicaciones ahora utilizan System.Configuration [1, 2].Dado que esto también está basado en XML, parece que todo se está moviendo en la dirección del uso de XML para la configuración.

Si desea seguir siendo multiplataforma, diría que usar algún tipo de archivo de texto sería el mejor camino a seguir.En cuanto al formato de dicho archivo, es posible que desees tener en cuenta si un humano lo va a manipular o no.XML parece ser un poco más fácil de manipular manualmente que los archivos INI debido a la estructura visible del archivo.

En cuanto al impuesto sobre los corchetes angulares, no me preocupo demasiado porque las bibliotecas XML se encargan de abstraerlo.El único momento en el que podría considerarlo es si tiene muy poco espacio de almacenamiento para trabajar y cada byte cuenta.

[1] Espacio de nombres System.Configuration - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Uso de archivos de configuración de aplicaciones en .NET - http://www.developer.com/net/net/article.php/3396111

Estamos usando archivos de propiedades, simplemente porque Java los admite de forma nativa.Hace un par de meses vi que SpringSource Application Platform usa JSON para configurar su servidor y parece muy interesante.I comparó varias notaciones de configuración y llegué a la conclusión de que XML parece ser la mejor opción en este momento.Tiene buen soporte de herramientas y es bastante independiente de la plataforma.

Re:comentario de epatel

Creo que la pregunta original era sobre la configuración de la aplicación que haría un administrador, no solo sobre el almacenamiento de las preferencias del usuario.Las sugerencias que dio parecen más para las preferencias del usuario que para la configuración de la aplicación, y generalmente no son algo con lo que el usuario lidiaría directamente (la aplicación debe proporcionar las opciones de configuración en la interfaz de usuario y luego actualizar los archivos).Realmente espero que nunca obligue al usuario a ver/editar el Registro.:)

En cuanto a la pregunta real, diría que XML probablemente esté bien, ya que mucha gente estará acostumbrada a usarlo para la configuración.Siempre que organice los valores de configuración de una manera fácil de usar, el "impuesto del soporte angular" no debería ser tan malo.

Tal vez sea un poco tangente aquí, pero mi opinión es que el archivo de configuración debe leerse en un diccionario de valores clave/tabla hash cuando la aplicación se inicia por primera vez y siempre se debe acceder a través de este objeto a partir de ese momento para mayor velocidad.Normalmente, la tabla clave/valor comienza como una cadena a otra, pero las funciones auxiliares en el objeto hacen cosas como DateTime GetConfigDate (clave de cadena), etc.

Creo que lo único importante es elegir el formato que prefieras y puedas navegar rápidamente.Tanto XML como JSON son buenos formatos para configuraciones y cuentan con un amplio soporte; creo que la implementación técnica no es el meollo del problema.Se trata 100% de lo que le facilita la tarea de los archivos de configuración.

Comencé a usar JSON porque trabajo bastante con él como formato de transporte de datos y los serializadores facilitan la carga en cualquier marco de desarrollo.Encuentro que JSON es más fácil de leer que XML, lo que hace que manejar múltiples servicios, cada uno usando un archivo de configuración que se modifica con bastante frecuencia, sea mucho más fácil para mí.

¿En qué plataforma estás trabajando?Recomiendo intentar utilizar el método preferido/común para ello.

  1. MacOSX - listas
  2. Win32 - Registro (o hay uno nuevo aquí, hace mucho que lo desarrollé)
  3. Linux/Unix - ~/.apprc (quizás nombre-valor)
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top