ASP.MVC application constants, what is the best/most elegant approach?

Question

Simple question really,

I am just looking for community support what works best architecturally.

Say, following case: TempData["MySetting"]? Where should I store "MySetting"? Should it be

1. in separate class so that the access will be TempData[Config.MySetting];
2. in web.config so that the access is TempData[ConfigurationManager.AppSettings["MySetting"];
3. inline, leave it as string TempData["MySetting"];?

4. in the DB in some constants table, so that

   var mySetting = (string)_db.GetConstant("MySetting");
   TempData[mySetting];
   

I would not deal with option 4, just brought it for completeness of the picture. So what do you suggest and why?

Edit Question is rather general about constants in asp mvc rather than TempData case.

Thanks.

Answer 1

In your particular case you should make a wrapper around TempData which will expose your data as property. All the access to TempData should be hidden inside that wrapper. In this case all the usages of "MySetting" will be limited to at most two. If there's only one usage, you don't need to do anything. If there're two - you define your "MySetting" as private const field.

In short:

public static class TempDataWrapper
{
    private const string _mySettingName = "MySetting";

    public int MySetting
    {
        get { return (int) TempData[_mySettingName];}
        set { TempData[_mySettingName] = value;}
    }
}

For the sake of brevity we are not dealing here with coupling (which is tight) and error-handling (which is none).

Answer 2

I would go with:

public static class Config
{
    public static readonly string MyValue = "SomeValue";
}

More about Const vs Readonly

Answer 3

Do your settings change? Depending on environment you deploy? If yes, then you definitely want to store them in the Web.config file (you could even make a custom section if it's not as simple as a couple of key/value pairs).

If they're the same on all the environments you use (including your own development box, the server and any testing/staging machines you might want to deploy) then I would go for the first option: declare a class with a few constants.

As far as storing them in the database goes, it really depends what kind of settings. If you want them to be per-user of your website, then you might end up storing them in your database. Or in case you want to be able to change them (editing the web.config file while the website is running is not the best idea).

I'd try staying away from leaving it as it is, inline.

Answer 4

You can try this approach:

public static class Constants
{
       public static class Actions
       {
            public const string Administration = "Administration";
       }
}

Answer 5

Well, assuming that your constants are really constants, they will not change at runtime. For this scenario you use the const field modifier and in some cases static readonly modifiers to set up your constants values.

public class MyConstants {
    public const string MyConstantNameValue = "Value";
    public const int MyConstantNameValue2 = 123;

    // prevent the class to be instantiated
    protected MyConstants() { }
}

As you see you don't define the MyConstants as a static class because you can extend the constants if you need another set of constants for a specific namespace for example (plus the global constants).

public class MyConstantsPlusSpecificNamespaceConstants : MyConstants {
    public const string MySpecificConstantName = "Value2";
}