I have an application that uses SQLite, which is extremely light weight and quick. I have some preferences that don't necessarily need to be loaded on startup, but might need to be used at various times depending on where the user goes. That being said, I can't decide where to store this information.
Q1: Should I just go ahead and store it in the database? Should I store it in a config file?
Q2: Should I load and store the preferences and other data at startup even if they're not necessarily being used right away? Or should I just query the database when I need them?
Example: My application can store the company information for the company that is using the software. Company name, company phone, etc. The only time this information is used is when the software auto-prints a letter, or the user goes to edit their company information in the program.
EDIT: I've realized that this comes down to application settings vs user settings. My program does not have multiple users per copy of the software. That being said, I would suppose these would be application settings.
What you may want to do is write a class that encapsulates the settings and then reads them into Hashtable.
You could have a basic GetSetting method that looks up a setting based on a name. If the setting is located in the Hashtable, return the value, otherwise go to the DB to find the setting and then store it in the Hashtable. You can then write separate properties for each setting you want, each calling the GetSetting/SetSetting methods.
This allows you to store the settings in the DB easily, and caches the reads to avoid constantly reading the DB.
public class Settings {
private object SyncRoot = new object();
private System.Collections.Hashtable _cache = new System.Collections.Hashtable();
public T GetSetting<T>(string xPath, T defaultValue)
{
lock (SyncRoot)
{
if (!_cache.ContainsKey(xPath))
{
T val = GetSettingFromDB<T>(xPath, defaultValue);
_cache[xPath] = val;
return val;
}
return (T)_cache[xPath];
}
}
public T GetSettingFromDB<T>(string xPath, T defaultValue)
{
// Read from DB
}
public void SaveSetting<T>(string xPath, T value)
{
lock (SyncRoot)
{
if (_cache.ContainsKey(xPath))
_cache[xPath] = value;
}
SaveSettingToDB<T>(xPath, value);
}
public T SaveSettingToDB<T>(string xPath, T defaultValue)
{
// Read from DB
}
}
Then just create a class with a bunch of properties like this:
public static bool BooleanFeature
{
get { return Settings.GetSetting<bool>("BooleanFeature", true); }
set { Settings.SaveSetting<bool>("BooleanFeature", value); }
}
Now you can do this in your code:
if (Setting.BooleanFeature) {
// Run certain code
else {
// Run other code
}
How many settings are you looking to save? Using the built-in settings feature is pretty painless.
http://msdn.microsoft.com/en-us/library/aa730869.aspx
Storing configuration data in a file is good for light-weight settings that rarely change. Usually you'd do this for settings that are different between development and production and are used to get your application up and running.
After that, everything else is best stored in a database. This gives you the option for good user interfaces to modify the settings, load them when needed, save them during upgrades to your system, be available if you're using multiple front-ends (versus saving the configuration in a file and ensuring all front-ends have the same up-to-date files.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With