7

.NET applications developed using Visual Studio have an easy way to store and recover user settings. You can add the default value of a setting in a special class and have read/write access to it at run time through Properties.Settings.Default.SettingName.

Some applications have use for values to be remembered between sessions, which will have to be stored somewhere else than in memory. One possibility would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values.
The "settings" described above are essentially such a file, but the values that need to be remembered might not technically be settings. One example is the timestamp of the last time a certain function was performed.

One might argue against storing such a value in Properties.Settings as it is not a setting (i.e. user preference) and therefore the namespace's name would cause confusion.
Is there, however, a practical reason not to use Properties.Settings to store such a value?

George T
  • 295

2 Answers2

2

You wrote

Some applications have use for values to be remembered between sessions

well, that is true whenever you have to persist data

would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values. [...] One example is the timestamp of the last time a certain function was performed.

So you are talking about data which has to be persisted per user (maybe also per machine), and where it is not "mission critical" if they got lost because of a missing backup. That is IMHO exactly the use case for Properties.Settings

the values that need to be remembered might not technically be settings.

But why not? Because you associate something different with that term? I would not be so picky about the term - just because Microsoft choose the name Settings for that class, and did not call the class SettingsAndOtherUserPersistentData should not hinder you to use the mechanism for your purpose, as long as it fits to the scenario I scetched above.

Doc Brown
  • 218,378
1

Properties.Settings are stored for the user on the machine. If you want the settings to be common to all users and/or all machines, this method would not do. You also may want to have input parameters for the application that steer its behavior rather than preferences, and have several sets of them ready to be used in different senarios. For this, Properties.Settings would not be right or usable either since there is just one hidden set that cannot be changed externally in an easy and obvious manner (you can not start the application instructing it to use a particular set). You could however load input parameters from Properties.Settings once the application is up.

Properties.Settings is a quick way to persist some stuff but will soon fall apart as your application grows due to lack of flexibility and vagueness regarding the purpose of the data stored. You would want to separate input from personal preferences from administrative preferences from configuration from environment settings from whatever further applies to your software. And each may have to be maintained separately by different people and be retrieved from different sources (database, registry, xml document, environment variables).

Martin Maat
  • 18,652