Configuration data

Configuration data

Old forum URL:

Brendt posted on Thursday, September 19, 2013

Good day.

i would like some guidance in the following please. i would like to be able to load configuration data through having my businessLibrary and Factory classes. i have all my other classes (eg. customer classes) which use the Factory implantation, but i am unsure on how to proceed with the configuration aspect of things.

i would like to load configuration data from my database when my application loads and have that information readily available throughout my entire application, irrespective of which form or class i am currently working in. 

would/could i create a static class (of businessbase) class and just call it every time i need it (how could this be done)


should i have it like all other classes in my application BusinessLibrary classes and instantiate it and just pass the object to every form and class that would need this data?

any help or advice in this regard would be highly appreciated.

JonnyBee replied on Thursday, September 19, 2013

A couple of techniques worth considering

  1. A static Context class with a static property for the config class (somewhat a variant of Singelton)
    (or you can also use ApplicationContext in CSLA)
  2. Use the Singelton pattern to make the config class hold just one instance
    And: MSDN Implementing Singleton in C#
  3. Use an IOC container and set configuration to single/shared instance

skagen00 replied on Thursday, September 19, 2013

In our application (Silverlight) we do this in the startup - our class is called something along the lines of "ConfigurationData".  It has a number of children BOs - mostly BLBs - which contain configuration data.

When calling the fetch on this, like ConfigurationData.GetConfigurationData, the criteria is set of "hash" codes of sorts from what was kept in IsolatedStorage from the last application run.  (Note that 32-bit and 64-bit implementations of string GetHashCode() are different so you have to do something about that, it's not that hard). 

On the data access side of this ConfigurationData fetch, it does a factory fetch of each of the configurationdata components individually and gets the hash code - if they match, "null" is sent back for that part of configurationdata - telling the client they have the most recent version.  This allows our pre-load of configuration data to be pretty economical when things haven't changed - not a ton of stuff ends up coming back to the client in most cases.

Each component of the data, when "changed", is loaded into the ConfigurationData object.  When everything gets back to the client then IsolatedStorage is updated for the next time.

The callback of the GetConfigurationData is when we move our application UI into the main content of the root visual.  Before then, we have a "loading application data" UI w/ spinner.

Using hashcodes to check for changes as well as lumping everything into one main business object (with various child components) and one intiial call ends up being a very efficient way of handling this.

Copyright (c) Marimer LLC