4

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.

Display Name
  • 4,672
  • 1
  • 33
  • 43

5 Answers5

4

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

Sergei Rogovtcev
  • 5,804
  • 2
  • 22
  • 35
  • Thanks. My question was rather general than specific. How to deal with different constants inside the MVC app? – Display Name Aug 11 '12 at 19:48
  • The same way as in any other app. They are *constants* - they should be hard-coded. All the other things depend on usage, and *on usage only*. There's no such thing as general approach in this matter. – Sergei Rogovtcev Aug 11 '12 at 19:56
4

I would go with:

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

More about Const vs Readonly

Community
  • 1
  • 1
formatc
  • 4,261
  • 7
  • 43
  • 81
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.

Vlad Ciobanu
  • 1,473
  • 1
  • 11
  • 11
  • What you mentioned makes sense. Any other options besides 1-4? How to create custom section (no idea) - can please update the answer? Thanks for taking time – Display Name Aug 11 '12 at 19:33
  • You can check this URL for a good description on how to create a custom section for your Web.config: http://msdn.microsoft.com/en-us/library/2tw134k3.aspx As far as other options, it really depends on what exactly you are trying to store, and your specific application. – Vlad Ciobanu Aug 11 '12 at 20:05
3

You can try this approach:

public static class Constants
{
       public static class Actions
       {
            public const string Administration = "Administration";
       }
}
Aleksei Anufriev
  • 3,206
  • 1
  • 27
  • 31
1

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";
}
Marcelo De Zen
  • 9,439
  • 3
  • 37
  • 50