Usefulness of IApplicationSettings interface?

ksouthworth · December 17th, 2010, 12:48 AM

I'm curious about the usefulness of having the IApplicationSettings interface. Since it's in the Infrastructure project, I assume it's meant to be used across multiple separate projects/applications? But since the interface defines strongly-typed Properties, it seems to limit its usefulness? For example, the PayPalBusinessEmail property, if I use this interface in another project, that project might not have the concept of a PayPal Business Email.

It seems like the IApplicationSettings interface should just be a a Get() method and a Set() method to read/write settings? That way it's more portable across different projects? I would love to have strongly-typed application settings, but I don't see how we can have that AND portability across projects?

Something like:

Code:

public interface IApplicationSettings
{
object GetSetting(string name);
void SetSetting(string name, object value);
}

ksouthworth · December 17th, 2010, 12:53 AM

Or maybe this:

Code:

    public interface IApplicationSettings
    {
        T GetSetting<T>(string name);
        void SetSetting<T>(string name, T value);
    }

elbandit · December 17th, 2010, 04:54 AM

Hi ksouthworth,

Good point, you could still have strongly-typed application settings by creating a constants class for your setting names.

In the infrastructure project (shared across different projects) you would place your new IApplicationSettings interface.

Code:

   public interface IApplicationSettings
   {
       T GetSetting<T>(string name);
       void SetSetting<T>(string name, T value);
   }

In an assembly specific to the project you would create a key class:

Code:

    
    public static class ApplicationSettingKeys
    {
        public static readonly string PayPalEmail = "[email protected]";
    }

So you could then use them together like so:

Code:

 
var payPalEmail = AppSettings.GetSetting<String>(ApplicationSettingKeys.PayPalEmail);

Good stuff

Cheers
Scott

joefawcett · December 17th, 2010, 08:25 AM

Regarding your first point I'm not sure that the IApplicationSettings interface is designed to be used across multiple applications in the sense you mean. I see it more as designed to enable you to change the way settings are stored for a particular app.

For example we recenlty had a web app that stored many settings in the web.config. This became difficult to manage as access to the system was limited so we changed to storing the data in a database table. Having an interface like IApplicationSettings makes this sort of change much simpler.

ksouthworth · December 17th, 2010, 11:36 AM

Joe,
I guess it depends on how you view the purpose and intention of the "Infrastructure" project. If you want it to be used across multiple future projects, then I think the version of the interface with methods, along with Scott's changes, makes the most sense. If you only intend to use the Infrastructure among a single application's projects (e.g. Agatha's storefron) then keeping the interface with strongly typed properties works just fine.

I definitely agree that the purpose of the interface should allow the persistence strategy of the settings to be swapped out, like you described with using a database backend instead of web.config.