CODEWITHSUNDEEP
c#database-designsqliteinitialization
OogaBooga
OogaBooga

Reputation: 495

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.

Upvotes: 8

Views: 6019

Answers (4)

Oskar Kjellin
Oskar Kjellin

Reputation: 21870

In addition to JTAs answer I would like to add that I've used 3 methods and they all have their up and down sides.

  1. Storing them in the built-in one does actually lock them to the running user. So for instance if multiple users use your app, there will be independent settings for each user. If this is what you want, pick this one.

  2. Storing them in the database is useful if you do not want it to be bound to a user but rather to the database. Though you cannot change these settings from outside the app.

  3. I've used a config-class that I serialize with XML if I need to edit it with an xml-editor. For instance this is very useful if you are running a service.

Upvotes: 0

Chris Thompson
Chris Thompson

Reputation: 16841

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
}

Upvotes: 9

Erik Noren
Erik Noren

Reputation: 4339

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

Upvotes: 1

Inisheer
Inisheer

Reputation: 20794

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

Upvotes: 4

Related Questions