La mejor manera de guardar la configuración de la aplicación

17

En Windows, la forma predeterminada es el registro. Esto le permite diferenciar configuraciones de todo el sistema y por usuario.

En Unix, debe usar archivos de texto en la carpeta / etc para la configuración de todo el sistema (¿cuál es la convención para la configuración por usuario?).

Muchos programas nuevos (y especialmente aquellos diseñados para ser portátiles) usan archivos XML.

  • ¿Cuál es la mejor manera (y ubicación) para almacenar configuraciones que no sean BLOB?
  • ¿Deberíamos seguir los valores predeterminados de cada sistema o tener una solución unificada?
  • ¿Y cuál es la mejor forma portátil ?
portability Wizard79
fuente
Sea muy específico sobre lo que quiere decir con "mejor".
3
@ Thorbjørn: mejor adj \ ˈbest \ superlativo del bien
Wizard79
3
se sorprendería de la diversidad de significados de "mejor" en los sitios de StackExchange.

Respuestas:

23

¿Cuál es la mejor manera (y ubicación) para almacenar configuraciones que no sean BLOB?

En Windows, parece aceptable usar el registro. En mi opinión, el registro era un sistema mal diseñado y, en cambio Users\Username\AppData, debería preferirse un simple archivo de texto en el directorio. Esto es más fácil de respaldar, menos peligroso para los usuarios modificar y más fácil de limpiar.

En Linux y la mayoría de los Unix, la ubicación preferida es /home/user/.config/appnamepara configuraciones específicas del usuario y /etc/para configuraciones globales (de todo el sistema). La ubicación menos preferida (pero aceptable) para la configuración del usuario es ~/.appname, pero esto generalmente está cayendo en desgracia. Estos archivos deben ser editables por el usuario, por lo que siempre se prefiere un formato legible por humanos.

No estoy de acuerdo con la mayoría de las personas en que XML es un formato aceptable para almacenar datos que no son de blob. Es, en mi opinión, un formato excesivamente complejo y excesivamente complejo para lo que generalmente termina siendo piezas muy pequeñas de datos estructurados. Prefiero ver archivos en YAML, JSON, ASN.1, pares de nombre = valor o formatos similares. Tener demasiada sintaxis hace que sea demasiado fácil para un usuario equivocarse y dejar el archivo en un formato no válido.

¿Deberíamos seguir los valores predeterminados de cada sistema o tener una solución unificada?

Eso depende totalmente de usted, pero tenga en cuenta algunas cosas:

  • Las plataformas como * nix tienen limitaciones estrictas sobre qué ubicaciones se pueden escribir. Más estricto que Windows. Entonces:
    • El único lugar donde debe escribir es el directorio de inicio del usuario.
    • A menos que su aplicación sea un servicio del sistema; en cuyo caso, todos los archivos de datos mutables deben escribirse /var/. Archivos de datos Nonmutable deben mantenerse en su directorio de aplicación en /usr/share/o /usr/local/share/o/opt/
    • Los archivos de configuración en /etc/debe nunca se deben escribir en la aplicación cuando se está ejecutando, incluso si no tiene acceso de escritura a ellos. /etc/debería ser el repositorio de comportamientos predeterminados y nada más.
    • Plan para su aplicación a instalar en uno de tres lugares: /usr/local/, /opt/appnameo /home/username/appname.
    • Los blobs deben almacenarse junto con otros archivos de configuración si se van a cambiar. Generalmente es preferible usar un formato editable por el usuario, por lo que se prefiere algo como SQLite o Berkeley DB (ya que hay herramientas de línea de comandos para cada uno), pero no es obligatorio.
  • En Windows, sus aplicaciones solo deberían escribir en el directorio de usuarios. La ubicación estandarizada para los archivos de datos es Users\User\AppData. En ningún otro lugar parece aceptable.
  • En Mac OS X, la configuración de su aplicación debe almacenarse ~/Library/Preferencesjunto con todos los archivos plist de las otras aplicaciones. plistparece ser el formato preferido, pero querrá verificar con las pautas de Apple.

¿Y cuál es la mejor forma portátil?

No hay "mejor", para ser honesto. Solo hay limitaciones y expectativas específicas de la plataforma. Mi recomendación es seguir con los medios específicos de la plataforma, incluso si eso significa escribir más código.

Greyfade
fuente
1
Creo que Microsoft ha desalentado el uso del registro durante algunos años, lo cual es bueno. Escribir en AppData, como mencionó, es el camino a seguir. En .NET (¿tal vez también en la API de Windows?) Incluso hay un método que devuelve la ruta correcta.
MetalMikester
También hay una variable de entorno:%APPDATA%
greyfade
@MetalMikester: sí, absolutamente perfecto. AppData también es compatible con Roaming Profile para un entorno de dominio.
JBRWilkinson
settings! = config
Yousha Aleayoub
> In my opinion, the registry was a poorly-devised system, and instead a simple text file in the Users\Username\AppData directory should be preferred. @greyfade: Raymond Chen, desarrollador de la API de Windows desde hace mucho tiempo, aborda esto y explica por qué el uso de archivos de texto sobre el registro no es un mejor patrón de diseño: ¿Por qué los archivos INI están en desuso a favor del registro
Mick
8

En Windows, use %APPDATA%\appname. En * NIX, use ~/.appname. No use nombres de directorio fijos en ninguna de las plataformas, ya que el directorio de inicio del usuario puede ser diferente del predeterminado (podría estar en la red, por ejemplo).

En cuanto al formato, use lo que considere mejor. Esa es una decisión que solo usted puede tomar en el contexto de su solicitud. Es innecesario, y de hecho, desaconsejable, tener una forma "estándar" de hacerlo, si esa forma "estándar" no es lo mejor para su programa en particular.

Por ejemplo, XML / JSON podría ser una buena forma de almacenar datos / configuración del usuario si su aplicación ya usa XML / JSON para otra cosa. Pero si se trata de un archivo de configuración simple, ¿por qué agregar hinchazón a su aplicación introduciendo una dependencia? En ese caso, probablemente sea mejor usar un archivo de texto simple con var: value\nlíneas.

EDITAR: No hay una "mejor" forma portátil, ya que los sistemas operativos utilizan convenciones muy diferentes para esto. No rompas los estándares del sistema operativo sin una buena razón.

EDIT2: si te encuentras haciendo una configuración de todo el sistema en /etco HKEY_LOCAL_MACHINE, pregúntate si la configuración es realmente global. Luego espere 5 minutos y pregúntese nuevamente. Si la respuesta sigue siendo sí, entonces, por supuesto, haga una configuración global. Recuerde, un usuario normal no tiene acceso de escritura /etco, HKEY_LOCAL_MACHINEy al hacer esto, se asegura de que alguien sin derechos de administrador no pueda instalar su aplicación.

Chinmay Kanchi
fuente
El primer párrafo permite usar Path.Combine o algo similar y, por lo tanto, establecer la ubicación raíz relativa una vez en% APPDATA% o ~ y dejar que el código haga el resto, para EDIT2 no existe una solución multiplataforma que conozco de. Tal vez hay personas que han escrito una biblioteca de configuración multiplataforma para tal fin, por lo menos sería una buena idea ...
Tamara Wijsman
1
@TomWij: Seguramente, cualquier desarrollador competente debería ser capaz de darse cuenta de que no necesita usar literales en todas partes;). Para eso están las variables.
Chinmay Kanchi
1
~/.config/applicatonse está convirtiendo cada vez más en la ubicación preferida en * nix.
greyfade
@greyfade: Nunca me di cuenta de esto, pero tienes razón. En mi máquina, aproximadamente una cuarta parte de las aplicaciones que almacenan datos de configuración ~lo hacen en ~/.config/appname.
Chinmay Kanchi
Un montón de aplicaciones usan ~ / .appname en Windows (lo que equivale a su directorio de perfil de usuario, NO documentos) y es muy molesto. ¡Esas carpetas no se esconden!
Alan Pearce
3

Intento mantenerme fuera del registro, está muy usado. Desearía que todos lo hicieran.

Me gusta mantener archivos de configuración xml o un archivo bin u ocasionalmente una base de datos local (SQLite).

µBio
fuente
+1 por mantenerse fuera del registro. No puedo encontrarlo ahora, pero parece recordar haber leído que alguien en MS admitió que el registro fue un error.
Chinmay Kanchi
1
De acuerdo con usted, excepto la parte XML. Usaría ini (o archivo de texto simple) para requisitos de configuración simple y SQLite para aplicaciones complejas.
Codismo
¿Están admitiendo eso ahora? ¡Pude decírtelo en 1995! Mac OS Classic lo hizo bien: una carpeta de Preferencias para darle un lugar centralizado para almacenar información de configuración, con cada aplicación guardada en su propio archivo. Cuando vi el Registro por primera vez, pensé: "¿Microsoft nunca ha oído hablar de no poner todos sus huevos en una canasta?"
Mason Wheeler
1
Creo que es un lugar para poner la configuración del sistema operativo (como el registro de extensión de archivo, etc.), está bien. Pero si Microsoft lo publicara como una API de solo lectura, probablemente habrían sido demandados por ello y de todos modos tendrían que hacerlo escribible.
µBio
@Chinmay, @Mason, el registro NO ES un error porque el registro hace MUCHO más que solo almacenar datos de configuración (ver: política de grupo, dominios, replicación). El error es cómo Microsoft lo lanzó a los desarrolladores y la falta de un buen estándar sobre cómo usarlo. Terminó como un vertedero de datos de la aplicación, que no es para lo que estaba destinado.
Matt Olenik
3

Mi respuesta es una combinación de Chinmay de Kanchi respuesta y de BioBuckyBall respuesta .

XML / Json para configuraciones simples, SQLite para configuraciones complejas y más grandes estacionadas en la carpeta predeterminada de la aplicación del sistema operativo o la carpeta predeterminada del usuario del sistema operativo cuando las configuraciones dependen del usuario. Ambos podrían ser utilizados.

Maniero
fuente
2

En Windows, mantendría la configuración de la aplicación en la AppDatacarpeta

Graviton
fuente
1

La configuración del usuario suele estar en 

/home/<user>/.<application>

Entonces, por ejemplo, la configuración de irssi es /home//.irssi/config

Chris
fuente
Pero esta es una convención de Unix. ¿Qué hay de Windows? Y en Linux, ¿no inunda el directorio de inicio del usuario con subdirectorios? ¿Por qué no /home/<user>/etc/application?
Wizard79
@Lorenzo: Inundar el directorio de inicio del usuario rara vez es un problema.
Chinmay Kanchi
1
Los ajustes de configuración se mueven cada vez más ~/.config/applicationpara ayudar a mantener las cosas consolidadas. Me inclino a estar de acuerdo con este movimiento.
greyfade
1
@Lorenzo: Esto es exactamente lo mismo que la convención de Windows de almacenar archivos de configuración AppData.
greyfade
1
@ Chris: de ninguna manera! :-)
Wizard79
1

Creo que es mejor usar el mecanismo preferido de plataforma específica. Por ejemplo, en OS X, el mecanismo preferido es colocar una lista de propiedades en ~ / Library / Preferences, y la API de Cocoa tiene una interfaz realmente simple para almacenar y recuperar configuraciones desde allí.

Si su aplicación es multiplataforma, puede abstraerlo con una clase o cualquier otra cosa.

mipadi
fuente
0

Lo único que escribo en el registro es la ubicación de la aplicación, para que los instaladores y los actualizadores puedan encontrarla fácilmente. Todo lo demás se almacena en archivos en / AppData / Company / App

Gran maestro B
fuente
-2

Para aplicaciones Java creo que gson es una buena opción. Cree sus objetos de configuración y use gson para convertirlos a JSON y viceversa. Tiene la ventaja de ser legible para el ser humano en lugar de un blob serializado.

Editar: ok, entonces tal vez no sea tan general ...

FeatureCreep
fuente
-2

Si está escribiendo en .NET, puede usar System.Environment.SpecialFolders para averiguar qué ubicaciones de carpeta puede usar para guardar la configuración o incluso algunos datos.

James
fuente