Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

C# Application - storing of preferences in database or config file?

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.

like image 898
OogaBooga Avatar asked Nov 07 '10 22:11

OogaBooga


3 Answers

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
}
like image 62
Chris Thompson Avatar answered Sep 28 '22 21:09

Chris Thompson


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

like image 25
Inisheer Avatar answered Sep 28 '22 19:09

Inisheer


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.)

like image 33
Erik Noren Avatar answered Sep 28 '22 21:09

Erik Noren