Is my parameters storing paradigm good?

Question

Hi. I develop next application parameters storing paradigm:

There is enum for each parameter roles

enum ParameterRole
{
    FileName,
    FileDir
}

Parameters are contained in special container as object

class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
 get
 {
  if (base.ContainsKey(role))
  {
   return base[role];
  }
  else
  {
   return null;
  }
 }
 set
 {
  if (base.ContainsKey(role))
  {
   base[role] = value;
  }
  else
  {
   base.Add(role, value);
  }
 }
}
}

It's private member of AppSettings class

class AppSettings {    
ParamContainer  container = new ParamContainer();

public string FileName
{
    get
    {
        return container[ParemeterRole.FileName] as string;
    }
    set
    {
        container[ParemeterRole.FileName] = value;
    }
}
}

and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.

What benefits? You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic. What deficiencies? Parameter values are stored as object and it uses more memory as it could, I guess, if was stored as it's corresponding types.

What do you think about it? It's very interesting and important for me. Is it rubbish or could be useful?

Answer 1

Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:

    get
    {
        object value;
        TryGetValue(role, out value);
        return value;
    }
    set
    {
        base[role] = value;
    }

Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).

Answer 2

If using of an enum is bad practice, what is the way to hold all keys in one container and how to access them directly without linear search, etc ?