windows - son - registry traduccion
Mejores prácticas de registro de Windows (8)
A mí me parece más fácil pensar en lo que NO debes poner allí. por ejemplo: datos dinámicos, como el "último archivo abierto" de un editor y las opciones de proyecto. Es realmente molesto cuando la aplicación pierde la sincronización con el registro (eliminación de archivos, bloqueo del sistema, etc.) y recupera información que ya no es válida, posiblemente el interbloqueo del usuario.
En un trabajo anterior, vi a un tipo que almacenaba un porcentaje de finalización de la transferencia de datos allí, escribiendo los nuevos valores cada 10k aproximadamente y haciendo que la GUI recuperara este valor cada segundo para que pudiera aparecer en la barra de título.
¿De qué manera se debe utilizar el registro de Windows? Sé que está bien almacenar una pequeña cantidad de preferencias de usuario, pero ¿se considera una mala práctica almacenar todos los datos de sus usuarios allí? Creo que dependería del conjunto de datos, entonces, ¿qué tal para pequeñas cantidades de datos, por ejemplo, menos de 2 KB, en 100 o más pares clave / valor diferentes? ¿Es esta mala práctica? ¿Sería una mejor práctica un archivo plano o SQLite db?
Como cada usuario tiene un espacio de directorio en Windows ya dedicado al almacenamiento de datos de usuario de la aplicación, lo uso para almacenar los datos de nivel de usuario (preferencias, por ejemplo) allí.
En C #, lo obtendría haciendo algo como esto:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Normalmente, almacenaré los archivos de SQLite allí o lo que sea apropiado para la aplicación.
Creo que Microsoft está fomentando el uso de almacenamiento aislado en lugar del registro de Windows.
Here''s un artículo que explica cómo usarlo en .Net.
Puede encontrar esos archivos en Windows XP en Documentos y configuración // Configuración local / Datos de la aplicación / Almacenamiento aislado. Los datos están en archivos .dat.
El uso del registro para almacenar datos tiene principalmente un problema: no es muy fácil de usar. Los usuarios no tienen prácticamente ninguna posibilidad de hacer una copia de seguridad de sus configuraciones, copiarlas en otra computadora, solucionarlas (o restablecerlas) si se corrompen o simplemente ver qué hace su software.
Mi regla de oro es usar el registro solo para comunicarse con el sistema operativo. Asociaciones de tipo de archivo, entradas del desinstalador, procesos para ejecutar en el inicio, esas cosas obviamente tienen que estar en el registro.
Pero los datos que se usan en su aplicación solo pertenecen a un archivo en su carpeta de Datos de la aplicación. (De todos modos, una de las más de 3 carpetas de datos de la aplicación que Microsoft quiere que uses ahora)
Me gustaría diferenciar:
Por un lado, hay datos de configuración específicos de la aplicación que se necesitan para que la aplicación se ejecute, por ejemplo, las direcciones IP a las que se conectan, qué carpetas usar para qué tipo de archivos, etc. y la configuración no trivial por usuario. Los que pongo en un archivo de configuración, formato ini para cosas simples, xml si se vuelve más complejo.
Por otro lado, hay configuraciones triviales por usuario (el mejor ejemplo: posiciones de ventana y diseño). Para evitar el desorden de los archivos de configuración (que algunos usuarios querrán editar ellos mismos, por lo que son imprescindibles algunas entradas claramente organizadas), me gusta colocarlos en el registro (con valores predeterminados conservadores establecidos en la aplicación si no hay configuraciones en el registro puede ser encontrado).
Principalmente lo hago como istmatt sais: istmatt archivos de configuración dentro de la carpeta %APPDATA% . Por lo general, en %APPDATA%/ApplicationName , no me gusta el valor predeterminado de .NET de APPDATA%/CompanyName/ApplicationName/Version , ese nivel de detalle y complejidad es contraproducente para la mayoría de las aplicaciones pequeñas y medianas.
No estoy de acuerdo con el ejemplo de Marcelo MD de no almacenar los archivos usados recientemente en el registro. En mi opinión, este es exactamente el tipo volátil de información específica del usuario que puede almacenarse allí. (¡Su ejemplo de lo que no se debe hacer es muy bueno, sin embargo!)
Para mí, es mejor almacenar los elementos de configuración de usuario simple y los datos de usuario en un archivo de configuración XML simple, una base de datos SQLLite o una base de datos compacta de MS SQL Server. El medio de almacenamiento exacto depende de los detalles de la implementación.
Solo uso el registro para cosas que necesito configurar con poca frecuencia y que los usuarios no necesitan poder cambiar / ver. Por ejemplo, he almacenado información de licencia encriptada en el registro antes para evitar que el usuario elimine accidentalmente los datos.
Si su aplicación se implementará "en la empresa", tenga en cuenta que los administradores pueden modificar el registro mediante herramientas de políticas de grupo. Por ejemplo, si Firefox usara el registro para cosas como el servidor proxy, haría que la implementación fuera fácil porque un administrador puede usar las herramientas estándar en el directorio activo para configurarlo. Si usas cualquier otra cosa, no creo que esas cosas puedan hacerse muy fácilmente.
Así que no descarte el registro todos juntos. Si existe la posibilidad de que un administrador quiera estandarizar partes de su configuración a través de una red, ponga la configuración en el registro.
Voy a tener una opinión contraria.
El registro es un buen lugar para colocar datos de configuración de todos los tipos. En general, es más rápido que la mayoría de los archivos de configuración y más confiable (las operaciones individuales en el registro se tramitan, por lo que si su aplicación falla durante una escritura, el registro no está dañado, en general no es el caso de los archivos ini).
Marcelo MD tiene toda la razón: almacenar cosas como el porcentaje de operación completa en el registro (o cualquier otro almacenamiento no volátil) es una idea horrible. Por otro lado, almacenar datos como los archivos utilizados más recientemente está bien: el registro se creó para ese tipo de problema.
Varios de los otros comentaristas en esta publicación que hablan sobre la lista de MRU han discutido el problema de lo que sucede cuando la lista de MRU se desincroniza debido a fallas en la aplicación. Me pregunto por qué es mejor almacenar la lista MRU en un archivo plano en el almacenamiento por usuario.
Tampoco estoy seguro de cuáles son las "implicaciones de seguridad" de almacenar sus datos en el registro. El registro es tan seguro como el sistema de archivos: el registro y el sistema de archivos utilizan el mismo mecanismo de ACL para proteger sus datos.
Si va a almacenar sus datos de usuario en un archivo, debe poner sus datos en% APPDATA% / CompanyName / ApplicationName al menos, de esa forma si dos desarrolladores diferentes crean una aplicación con el mismo nombre (cuántos "Administrador de medios" las aplicaciones están ahí fuera?) no tendrás colisiones.