It is very easy when creating a website to fall into the trap of duplicating small bits of information throughout your site.  It may seem expedient to hard-code something like your phone number or email in your views, especially initially when you may only reference it in one or two places.

However, once you start duplicating that information in several places it becomes too easy to make simple mistakes.  Maybe you misspell your email address on your contact page, resulting in valuable emails getting lost.  Or perhaps you change your  support phone number and forget to update your help page.

The easy solution is to place those strings in a single location and reference that location each time you need to display it.  Here are 4 common ways to store and access constants in your ASP.NET MVC website.

Class Constant

Probably the easiest and most familiar way (for C# developers) to create a constant is to use the const keyword on a class property.

public static class Constants {
  public const string SampleEmail = 
         "example@example.com";
}

Just make sure the class is accessible to your views and you can access the SampleEmail property like any other property.

This also lets you easily access the value in your controllers, which is useful for email addresses.

The drawback is that you will need to recompile and redeploy your website anytime you need to make modifications to the constant.  This can become tedious and introduces new opportunities for mistakes to occur.

Partial Views

Another option is to use a partial view to display the value. This is especially useful if you want to enforce a certain format or style for the information.  For example, to display a formatted address in several locations just create a Partial View called “_address.cshtml” in your “Shared” views directory, and add your address to it:

<address>
  <strong>Jane Doe</strong><br>
  123 MyAddress Lane<br>
  SomeCity, AnyState, US<br>
  <abbr title="Phone">P:</abbr> (555) 555-5555
</address>

Since a partial page can contain markup, you can specify the exact appearance of the address.  Then call Html.Partial from your view.

@Html.Partial("_address.cshtml")

This works really well as long as you don’t need to access the information in your controllers.   You can also update and deploy your partial view independently of the rest of your site, so you do not need to recompile and redeploy everything.

Web.config appSettings

A somewhat more controversial location to store constants is in the appSettings element of your web.config file.

<appSettings>
  <add key="email" value="example@example.com" />
</appSettings>

This method is convenient because you can update your constants by simply changing the web.config and replacing it on your server.  You can also access these values from anywhere in your application through the AppSettings table in the ConfigurationManager class.

System.Configuration.ConfigurationManager.AppSettings["email"]

Unfortunately, you can only access these properties through the string key used in the web.config, meaning you lose the benefits of intellisense and compile-time checks.

In addition, some feel that the web.config file should be reserved for true application settings and not simple view constants.  Constants such as email addresses can be both, so there can be a bit of a gray area.

Resources

The final solution for view constants is the most flexible – the resource file.  If you have any intention of ever creating an international version of your site, the resource file is the way to go.

To create a resource file, simply add one to your project.  Be sure to set the access modifier to the correct settings (basically avoid the “No Code Generation” option), then build your project.

Building will automatically generate a class for you to easily access your resources.  So if you created a resource file “ViewResources.resx” with a string resource called “PhoneNumber”, you could access that string in your code with the generate PhoneNumber property in the ViewResources class:

ViewResources.PhoneNumber;

This is quite convenient since it generates the wrapping code for you, eliminating the error-prone need to hard-code the string key access.

Unfortunately, since the resource file is embedded in the DLL, you will need to recompile and redeploy your site when you want to change these values.

On the other hand, using resource files puts you one step closer if you ever need to localize your site.

Conclusion

As you can see, none of these methods are perfect for every scenario.  I tend to use a mixture of methods depending on my specific needs, but no matter what you use, you will be better off than hard-coding values throughout your application.