¿Existe alguna razón práctica para no usar una "configuración" de .NET para almacenar datos que no sean una configuración?

7

Las aplicaciones .NET desarrolladas con Visual Studio tienen una manera fácil de almacenar y recuperar la configuración del usuario. Puede agregar el valor predeterminado de una configuración en una clase especial y tener acceso de lectura / escritura en el tiempo de ejecución a través de Properties.Settings.Default.SettingName .

Algunas aplicaciones se utilizan para recordar valores entre sesiones, que deberán almacenarse en otro lugar que no sea la memoria. Una posibilidad sería crear un archivo de un formato específico (XML, JSON, ini o algo más) en el directorio de datos del usuario y usarlo para dichos valores.
Las "configuraciones" descritas anteriormente son esencialmente un archivo de este tipo, pero los valores que deben recordarse pueden no ser técnicamente configuraciones. Un ejemplo es la marca de tiempo de la última vez que se realizó una determinada función.

Uno podría argumentar contra el almacenamiento de dicho valor en Properties.Settings , ya que no es una configuración (es decir, la preferencia del usuario) y, por lo tanto, el nombre del espacio de nombres causaría confusión.
Sin embargo, ¿existe una razón práctica para no usar Properties.Settings para almacenar dicho valor?

    
pregunta George T 08.06.2016 - 15:38

2 respuestas

2

Usted escribió

  

Algunas aplicaciones se utilizan para recordar los valores entre sesiones

bueno, eso es cierto siempre que tenga que conservar los datos

  

sería crear un archivo de un formato específico (XML, JSON, ini o algo más) en el directorio de datos del usuario y usarlo para dichos valores. [...]   Un ejemplo es la marca de tiempo de la última vez que se realizó una determinada función.

Por lo tanto, está hablando de datos que deben persistir por usuario (quizás también por máquina), y donde no es "de misión crítica" si se perdieron debido a una copia de seguridad faltante. Eso es IMHO exactamente el caso de uso para Properties.Settings

  

los valores que deben recordarse pueden no ser técnicamente configuraciones.

Pero ¿por qué no? ¿Porque asocias algo diferente con ese término? No sería tan exigente con el término, solo porque Microsoft elija el nombre Settings para esa clase, y no llamó a la clase SettingsAndOtherUserPersistentData no debería impedirle usar el mecanismo para su propósito, siempre que sea adecuado el escenario que he marcado arriba.

    
respondido por el Doc Brown 16.06.2016 - 07:44
1

Propiedades. Las configuraciones se almacenan para el usuario en la máquina. Si desea que la configuración sea común para todos los usuarios y / o todas las máquinas, este método no funcionaría. También es posible que desee tener parámetros de entrada para la aplicación que guíen su comportamiento en lugar de las preferencias, y tener varios conjuntos de ellos listos para ser utilizados en diferentes senarios. Para esto, las Configuraciones de Propiedades tampoco serían correctas o utilizables, ya que solo hay un conjunto oculto que no se puede cambiar externamente de una manera fácil y obvia (no puede iniciar la aplicación indicándole que use un conjunto en particular). Sin embargo, podría cargar los parámetros de entrada desde las Propiedades.Ajustes una vez que la aplicación esté activa.

Propiedades. La configuración es una forma rápida de conservar algunas cosas, pero pronto se desmoronará a medida que su aplicación crezca debido a la falta de flexibilidad y vaguedad con respecto al propósito de los datos almacenados. Desearía separar la entrada de las preferencias personales de las preferencias administrativas de la configuración de la configuración del entorno de lo que se aplique a su software. Y es posible que cada persona deba mantenerlas separadas y recuperarse de diferentes fuentes (base de datos, registro, documento xml, variables de entorno).

    
respondido por el Martin Maat 16.06.2016 - 07:26

Lea otras preguntas en las etiquetas