I recently stumbled across something with ASP.NET MVC action filters where they weren’t being executed in quite the order I was expecting. More specifically, I had made a poor assumption that filters defined at the Controller level would all execute prior to any action-level filters. After all, that was the behavior I thought I had seen before, but it turned out that it worked a bit differently. In this post I will explore exactly how ASP.NET MVC finds and orders filters, and what your options are for working with it.

Introduction to ActionFilterAttribute

I’ll start off with a quick introduction to ActionFilterAttribute, in case you are not familiar with it. ActionFilterAttribute is an sbtract class you can extend to gain access to different injection points in the execution of an action method. The attribute can decorate either an action method or an entire controller. In the case of decorating the controller, the filter will get applied to any action method inside that controller. If an action method in that controller also defines the same filter, and that filter does not allow for multiple instances, the filter on the action gets overridden by the one on the controller. In this example, both FilterOne and FilterTwo will be applied to the Index() action:

[FilterOne()]
public class HomeController : CustomController
{
	[FilterTwo()]
	public ActionResult Index()
	{
		return View();
	}
}

For more information on the basics of using filters, check out this article.

Keeping Your Filters In Order

What happens when you need your filters to execute in a certain order? Fortunately, the attribute provides an Order property for just such an occasion, but it comes with certain behaviors to keep in mind. First, it’s important to remember that filters that implement OnActionExecuting or OnActionExecuted will fire before any filters that do not, simply because those events happen first. You are also restricted to entering values of 0 or greater. Otherwise, filters are applied in ascending order according to the value of their Order property.

If no value is provided, the default value for Order is -1. This is exactly where my original confusion came in: any filter that does not specify a value for Order will fire before any filter that does, since -1 is less than 0. One I introduced a strict order for the filters on my base controller, I started seeing all the other filters executing before them, which was definitely not ideal.

Implementation Details

Since ASP.NET MVC is open source, I figured I would take a look to see how it was implemented to help see what my options were for working around my problem. The Controller class has a property called ActionInvoker, defined as:

public IActionInvoker ActionInvoker {
	get {
		if (_actionInvoker == null) {
			_actionInvoker = CreateActionInvoker();
		}
		return _actionInvoker;
	}
	set {
		_actionInvoker = value;
	}
}

protected virtual IActionInvoker CreateActionInvoker() {
	return new ControllerActionInvoker();
}

By default, it holds an instance of ControllerActionInvoker. In that class, there are a few methods that dictate how filters are discovered and applied for an action. The main starting point in here is the InvokeAction method, which as the name implies, tries to begin invoking a specific action on a controller. It retrieves a list of filters on the action by calling GetFilters(ControllerContext, ActionDescriptor):

protected virtual FilterInfo GetFilters(
    ControllerContext controllerContext,
    ActionDescriptor actionDescriptor) {
	FilterInfo filters = actionDescriptor.GetFilters();

	// if the current controller implements one of the filter interfaces, it should be added to the list at position 0
	ControllerBase controller = controllerContext.Controller;
	AddControllerToFilterList(controller, filters.ActionFilters);
	AddControllerToFilterList(controller, filters.ResultFilters);
	AddControllerToFilterList(controller, filters.AuthorizationFilters);
	AddControllerToFilterList(controller, filters.ExceptionFilters);

	return filters;
}

That method gets a list of filters from the action and then segments them off into different lists based on their type. You’ll see why this happens soon. The actual ordering of the filters happens in actionDescriptor.GetFilters():

internal static FilterInfo GetFilters(MethodInfo methodInfo) {
	// Enumerable.OrderBy() is a stable sort, so this method preserves scope ordering.
	FilterAttribute[] typeFilters =
            (FilterAttribute[])methodInfo
                .ReflectedType
                .GetCustomAttributes(typeof(FilterAttribute), true);
	FilterAttribute[] methodFilters =
            (FilterAttribute[])methodInfo
                .GetCustomAttributes(typeof(FilterAttribute), true);
	List<FilterAttribute> orderedFilters =
            RemoveOverriddenFilters(
                typeFilters.Concat(methodFilters)
            ).OrderBy(attr => attr.Order).ToList();

	FilterInfo filterInfo = new FilterInfo();
	MergeFiltersIntoList(orderedFilters, filterInfo.ActionFilters);
	MergeFiltersIntoList(orderedFilters, filterInfo.AuthorizationFilters);
	MergeFiltersIntoList(orderedFilters, filterInfo.ExceptionFilters);
	MergeFiltersIntoList(orderedFilters, filterInfo.ResultFilters);
	return filterInfo;
}

It grabs filters from the controller and action method, removes overridden filters based on the rules I mentioned earlier, and then orders them based on the Order property. If we jump back to the InvokeAction method, we can see that it executes authorization filters first, and then moves on to execute the remaining filters:

AuthorizationContext authContext =
    InvokeAuthorizationFilters(
        controllerContext,
        filterInfo.AuthorizationFilters,
        actionDescriptor);

if (authContext.Result != null) {
	// the auth filter signaled that we should let it short-circuit the request
	InvokeActionResult(controllerContext, authContext.Result);
}
else {
	if (controllerContext.Controller.ValidateRequest) {
		ValidateRequest(controllerContext);
	}

	IDictionary<string, object> parameters =
            GetParameterValues(controllerContext, actionDescriptor);
	ActionExecutedContext postActionContext =
            InvokeActionMethodWithFilters(
                controllerContext, filterInfo.ActionFilters,
                actionDescriptor, parameters);
	InvokeActionResultWithFilters(
            controllerContext, filterInfo.ResultFilters,
            postActionContext.Result);
}

Customization Options

So now we have seen how filters are applied, and the underlying implementation of it. What options are there for achieving the filter order you want?

In this case, the simplest solution is probably the best one – it just requires being aware of the traps we’ve talked about to avoid running into them. If you have define some filter order ranges, you can be sure that certain filters will be applied before others are run. The big catch of course is that it means every time you add a filter to an action or a controller you need to specify an order, to make sure it doesn’t get executed before the filters that should go first.

That said, ASP.NET MVC is full of extensibility points where you can plug in pretty much any behavior you want, so this seemed like a good chance to try that out again. For this example we’ll augment the existing ordering by also providing a way of prioritizing certain filters. To get started, let’s define two test filters that simply write out to the response stream when they get executed:

public class FilterOne : ActionFilterAttribute
{
	public override void OnActionExecuting(ActionExecutingContext filterContext)
	{
		filterContext.HttpContext.Response.Write("One<br />");
	}
}

public class FilterTwo : ActionFilterAttribute
{
	public override void OnActionExecuting(ActionExecutingContext filterContext)
	{
		filterContext.HttpContext.Response.Write("Two<br />");
	}
}

And then we’ll define a controller and action method for testing those filters:

[FilterOne(Order = 1), FilterTwo(Order = 2)]
public class HomeController
{
	public ContentResult Index()
	{
		return Content("");
	}
}

If you run it, you’ll see that FilterOne executes before FilterTwo, as expected. Now let’s build up a small framework for prioritizing filters. First, here is an extension method for IList I’ll use later to fluently add all items in a collection to a list:

public static class ListExtensions
{
	public static IList<T> AddAll<T>(this IList<T> destination, IEnumerable<T> source)
	{
		foreach (T item in source)
		{
			destination.Add(item);
		}

		return destination;
	}
}

For this example, a filter either is or isn’t prioritized, so there won’t be different levels of priority. To say a filter should get prioritized, it should implement the IPriorityFilter interface:

public interface IPriorityFilter
{
}

FilterTwo should be updated so that it is marked as a priority:

public class FilterTwo : ActionFilterAttribute, IPriorityFilter

Now we need to define our own custom IActionInvoker, which is where all the real logic goes. Since the default MVC ControllerActionInvoker does almost everything we want, we can leverage that and just swap out the part we want to change:

public class PrioritizedControllerActionInvoker : ControllerActionInvoker
{
	protected override FilterInfo GetFilters(
            ControllerContext controllerContext,
            ActionDescriptor actionDescriptor)
	{
		FilterInfo filterInfo = actionDescriptor.GetFilters();

		prioritizeFilters(filterInfo.ActionFilters);
		prioritizeFilters(filterInfo.AuthorizationFilters);
		prioritizeFilters(filterInfo.ExceptionFilters);
		prioritizeFilters(filterInfo.ResultFilters);

		return filterInfo;
	}

	private void prioritizeFilters<T>(IList<T> filters)
	{
		IList<T> originalFilters = filters.ToList();
		IEnumerable<T> priorityFilters =
                    originalFilters
                       .Where(filter => (filter as IPriorityFilter) != null);

		filters.Clear();

		filters
			.AddAll(priorityFilters)
			.AddAll(
				originalFilters.Except(priorityFilters)
			);
	}
}

It uses the default implementation of ActionDescriptor.GetFilters() so we don’t need to worry about all the details, and then just rearranges the order of the filters based on the presence of IPriorityFilter. Next we’ll need a custom controller that uses it:

public abstract class CustomController : Controller
{
	protected override IActionInvoker CreateActionInvoker()
	{
		return new PrioritizedControllerActionInvoker();
	}
}

Finally, update HomeController so that it uses the custom controller instead of the default one:

public class HomeController : CustomController

And that’s it! If you fire the page up again, you’ll see FilterTwo processed before FilterOne, even though the default ordering says otherwise.

The introduction of the dynamic keyword in C# 4.0 allows you to do a lot of things you couldn’t do otherwise, but it also makes it easy to forget that C# is still not a dynamic language, so there are limitations. Recently I found myself wanting to whip up a quick test page for something, with a very simple controller action and view. It wasn’t meant to be permanent, so creating a dedicated view model class in the project seemed like overkill. I figured I could just return an anonymous object as the model, and use a dynamic view to display it. I was wrong.

The Limits of Anonymous Classes

Let’s take a look at a quick example to demonstrate the problem. Here is my very simple controller action, that uses an anonymous class as the view model:

public ActionResult UsingDynamic()
{
  return View(new
  {
    TestString = "This is a test string"
  });
}

Now let’s make sure the data gets sent correctly to the view. First we’ll try just printing the model to the page using its ToString() method:

<%: Model %>

We get the output:

{ TestString = This is a test string }

So far so good! We see an object that has the TestString property and value we wanted. Now let’s try printing out the value of TestString:

<%: Model.TestString %>

This time ASP.NET throws an exception back at us, saying “‘object’ does not contain a definition for ‘TestString’”. How can this be? When we printed the object we could clearly see it had a property named TestString, and had a value for it. The answer here lies in the fact that anonymous classes are internal by default, meaning they are only accessible to the assembly in which they were created. Once you cross that assembly boundary, it gets treated as a regular object, which does not have the TestString property.

So if anonymous classes are internal, how can we accomplish what we want? There are a few ways I could think of.

Use a POCO

I know I said this was the solution I was trying to avoid, but I thought it was worth mentioning because in a majority of cases, having a well defined view model is a good choice. To wire this up using a defined view model, it would look something like this:

public class PocoViewModel
{
    public string TestString { get; set; }
}

And the controller action:

public ActionResult UsingPoco()
{
    return View(new PocoViewModel()
    {
        TestString = "This is a test string"
    });
}

The view would just need to inherit from ViewPage and it would work as expected.

ExpandoObjects

Another new addition in .NET 4.0 is the ExpandoObject. An ExpandoObject is an object that allows for dynamically adding and removing members at runtime. Since that is its purpose, it gets us something pretty similar to what we were trying to achieve with the anonymous class, but it will make it over the assembly boundary. The controller action using an ExpandoObject would look like:

public ActionResult UsingExpando()
{
    dynamic viewModel = new ExpandoObject();
    viewModel.TestString = "This is a test string";

    return View(viewModel);
}

The view should inherit from ViewPage (which is now actually the default), and it would be able to successfully access the TestString property. This is actually pretty much what they’re doing in ASP.NET MVC 3 with the new ViewModel property in Controller.

Dynamic Reflection

But what if you don’t want to use an ExpandoObject, and just want to throw an anonymous class at your view and have it just work? You can actually make this happen with an impressively small amount of code. First, we’ll create a custom dynamic class that wraps another object instance, and uses reflection to provide property access to that instance. To do that, the class will extend the DynamicObject class, which handles most of the heavy lifting for dealing with dynamics. If we wanted to do everything outselves, we could implement IDynamicMetaObjectProvider ourselves (which DynamicObject does), but in this case there’s no real reason to, so why not let DynamicObject do the hard work for us?

public class DynamicPageObject : DynamicObject
{
    private object _originalObject;

    public DynamicPageObject(object originalObject)
    {
        _originalObject = originalObject;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        result = _originalObject
                    .GetType()
                    .InvokeMember(binder.Name,
                                  BindingFlags.GetProperty
                                      | BindingFlags.Instance
                                      | BindingFlags.Public,
                                  null,
                                  _originalObject,
                                  null);

        return true;
    }
}

There we override the TryGetMember(…) function of DynamicObject, to allow it to use reflection over the original object to provide its member access. It’s pretty simple reflection, and that’s all there is to it.

Next we’ll create our own class that extends ViewPage that will automatically wrap the model in a DynamicPageObject:

public class DynamicPage : ViewPage
{
    public new dynamic Model { get; set; }

    protected override void SetViewData(ViewDataDictionary viewData)
    {
        base.SetViewData(viewData);

        Model = new DynamicPageObject(viewData.Model);
    }
}

We override the base Model property to use a dynamic model, which gets set to a DynamicPageObject that wraps around the original model. That’s all the code we need to make this work, so let’s give it a shot. The controller action is identical to the one from the original example, using an anonymous class:

public ActionResult UsingCustomDynamic()
{
    return View(new
    {
        TestString = "This is a test string"
    });
}

For the view, the only thing we need to do is have it inherit from DynamicPage and we’re done. Now we have a controller passing in an anonymous class as a view model, and a view that can handle that dynamically.

Since MongoDB is a document database, collections don’t have an enforced schema. Each document in a collection needs to store the names of all of its properties, making the length of that name more significant. Using abbreviated property names helps cut down on the storage space needed for each document, but it’s not ideal to mirror those abbreviated names in your object model. To help solve this problem, the NoRM driver provides an easy mechanism for defining custom mappings between the document and your model. First I’ll go through the standard way of doing it, and then I’ll present a custom solution that helps cut down on the amount of code you have to write by using attributes.

The Model

First, let’s define a very simple model for trying this out. I have an interface that all Mongo model objects will implement, that makes sure they have a Mongo identifier property:

public interface IMongoObject
{
    ObjectId Id { get; set; }
}

Then we have a Person class:

public class Person : IMongoObject
{
    public ObjectId Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }
}

In MongoDB, I have a collection named Person, populated with a small amount of data:

> db.Person.find();
{ "_id" : ObjectId("4c64077b763a000000002f4c"), "fn" : "Greg", "ln" : "Shackles" }
{ "_id" : ObjectId("4c640792763a000000002f4d"), "fn" : "John", "ln" : "Doe" }
{ "_id" : ObjectId("4c640796763a000000002f4e"), "fn" : "Jane", "ln" : "Doe" }

You can see there that the documents use “fn” and “ln” instead of “FirstName” and “LastName”. Since the data access classes aren’t what I want to focus on, here are the (very basic) DAO classes we’ll use:

public abstract class DaoBase<T>
    where T : IMongoObject
{
    private string _connectionString;

    public DaoBase(string connectionString)
    {
        _connectionString = connectionString;
    }

    protected IQueryable<T> FindAll()
    {
        using (var mongo = Mongo.Create(_connectionString))
        {
            return mongo.GetCollection<T>().AsQueryable();
        }
    }
}

public class PersonDao : DaoBase<Person>, IPersonDao
{
    public PersonDao(string connectionString)
        : base(connectionString)
    {
    }

    public IEnumerable<Person> FindAllPeople()
    {
        return FindAll();
    }

    public IEnumerable<Person> FindByLastName(string lastName)
    {
        return FindAll().Where(person => person.LastName == lastName);
    }
}

The Test

To make sure everything works, let’s set up a very simple page that will grab all the documents from the collection and display them as a list. Here’s the controller:

public class HomeController : Controller
{
    [Inject]
    public IPersonDao PersonDao { get; set; }

    public ActionResult Index()
    {
        var people =
            PersonDao
                .FindAllPeople()
                .OrderBy(person => person.LastName)
                .ThenBy(person => person.FirstName);

        return View(people);
    }
}

I’m using Ninject to create and inject the PersonDao dependency into the controller. That’s outside the scope of this post, but you can dig into the sample if you want to see how that works. Here’s the relevant part of the view:

<ul>
    <% foreach (var person in Model)
       { %>

        <li>
            <%: person.LastName %>, <%: person.FirstName %>
        </li>

    <% } %>
</ul>

Got Maps?

If you tried to run that test page right now NoRM would throw an error at you saying that it couldn’t find properties on Person for “fn” and “ln”. If you don’t tell it otherwise, it assumes that it should map a document property to a model property with the same name. To customize this we can define a MongoConfigurationMap. If you’re familiar with FluentNHibernate, this should feel pretty familiar.

public class PersonMap : MongoConfigurationMap
{
    public PersonMap()
    {
        For<Person>(config =>
        {
            config
                .ForProperty(person => person.FirstName)
                .UseAlias("fn");

            config
                .ForProperty(person => person.LastName)
                .UseAlias("ln");
        });
    }
}

Now NoRM will know to map a Person object, right? Almost. We just need to register that map so it knows to use it. In the constructor for PersonDao, let’s add this line to register it:

MongoConfiguration.Initialize(config => config.AddMap<PersonMap>());

Now if we fire up the test page we’ll get a nice ordered list of names, fresh out of MongoDB.

Using Attributes

Defining a map is very simple, but I didn’t like the idea of defining a new map for every class, just to set some string aliases. To get around that, I decided to create an attribute to put on properties that specifies an alias name, and then a custom map that uses reflection to create a map based on the attributes.

The attribute is very simple, and just takes in a string:

public class MongoAliasAttribute : Attribute
{
    public string AliasName { get; set; }

    public MongoAliasAttribute()
    {
    }

    public MongoAliasAttribute(string aliasName)
    {
        AliasName = aliasName;
    }
}

The heavy lifting all happens in the typed AttributeMap:

public class AttributeMap<T> : MongoConfigurationMap
{
    public AttributeMap()
    {
        var mappings = getAliasMappings();

        For<T>(config =>
        {
            foreach (var mapping in mappings)
            {
                config
                    .ForProperty(getPropertyByNameExpression(mapping.Key))
                    .UseAlias(mapping.Value);
            }
        });
    }

    private Expression<Func<T, object>> getPropertyByNameExpression(string propertyName)
    {
        ParameterExpression param = Expression.Parameter(typeof(T));
        UnaryExpression body =
            Expression.Convert(
                Expression.Property(param, propertyName),
                typeof(object)
            );

        return Expression.Lambda<Func<T, object>>(body, param);
    }

    private Dictionary<string, string> getAliasMappings()
    {
        var mappings = new Dictionary<string, string>();

        foreach (var item in typeof(T).GetProperties())
        {
            MongoAliasAttribute aliasAttribute =
                item.GetCustomAttributes(false)
                    .OfType<MongoAliasAttribute>()
                    .FirstOrDefault();

            if (aliasAttribute != null)
            {
                mappings.Add(item.Name, aliasAttribute.AliasName);
            }
        }

        return mappings;
    }
}

First, the getAliasMappings() function reflects on the current type, and finds any properties decorated with MongoAliasAttribute, returning a dictionary that maps property names to their aliases. Then for each mapping, it tells NoRM to alias the properties. Since the ForProperty method expects a lambda expression for specifying which property to alias, the getPropertyByNameExpression() function builds that expression.

Now to register this map with NoRM. To make this easier to use for other classes, let’s move the registration into DaoBase and remove the MongoConfiguration.Initialize() call from the PersonDao constructor. Next we’ll define a Map() method in the base class, and call it from the constructor:

protected virtual void Map()
{
    MongoConfiguration.Initialize(config => config.AddMap<AttributeMap<T>>());
}

Finally, we update the Person model object so that it specifies the aliases it wants to use:

public class Person : IMongoObject
{
    public ObjectId Id { get; set; }

    [MongoAlias("fn")]
    public string FirstName { get; set; }

    [MongoAlias("ln")]
    public string LastName { get; set; }
}

If we fire up the test page now everything should work exactly like it did when using PersonMap, and now we don’t need a new mapping class every time we want to alias properties in a new collection. The next step here, which I’ll leave as an exercise for the reader, is to automatically search the assembly for classes that implement IMongoObject and register an AttributeMap for each of them.

I recently discovered that despite the fact that I’d been using the TempData dictionary in my applications, I didn’t really have a full grasp on what it was doing behind the scenes. Of course this meant learning the lesson the hard way once something stopped working like I thought it would. I only really had myself to blame since in the end it was a simple case of RTFM, but it seemed like a good opportunity to dig in and see how TempData really works.

What is TempData?

Let’s start by describing what TempData gives you. Basically, it’s a bucket where you can dump data that is only needed for the following request. That is, anything you put into TempData is discarded after the next request completes. This is useful for one-time messages, such as form validation errors. The important thing to take note of there is that this applies to the next request in the session, so that request can potentially happen in a different browser window or tab. If you need something more persistent, Session is likely what you’re looking for.

Where Is TempData Stored?

This is the part that came back to bite me. By default, TempData is stored in the session. Yes, the session! Most of the time this probably doesn’t matter to you, since as long as you get your objects back when you want them you have no reason to worry about where it was kept. However, let’s say you decide you want to switch away from the default Session-State Mode, and use State Server Mode or SQL Server Mode. These modes require that all objects stored in session be serializable. This is exactly what I did, and without knowing that TempData used the session, it was non-obvious why I started seeing session errors.

You might have noticed that I said that TempData is kept in the session by DEFAULT, meaning you are not tied to that if you decide you don’t like it that way. Let’s take a look at some of the source code to ASP.NET MVC 2 and see how things work.

ITempDataProvider and SessionStateTempDataProvider
In the System.Web.Mvc namespace you’ll find a very simple interface called ITempDataProvider that looks like this:

public interface ITempDataProvider {
    IDictionary<string, object> LoadTempData(ControllerContext controllerContext);
    void SaveTempData(ControllerContext controllerContext,
                                IDictionary<string, object> values);
}

Not much to see there. It simply defines the methods of saving and loading the dictionary. In the same namespace is SessionStateTempDataProvider which implements ITempDataProvider. When loading the dictionary out of the session, it explicitly removes it afterwards to make sure only one request gets access to it:

public virtual IDictionary<string, object> LoadTempData(
    ControllerContext controllerContext) {

    HttpSessionStateBase session = controllerContext.HttpContext.Session;

    if (session != null) {
        Dictionary<string, object> tempDataDictionary =
            session[TempDataSessionStateKey] as Dictionary<string, object>;

        if (tempDataDictionary != null) {
            // If we got it from Session, remove it so that no other request gets it
            session.Remove(TempDataSessionStateKey);
            return tempDataDictionary;
        }
    }

    return new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);
}

The controller object has a public property for the TempData provider which that uses the session provider by default:

public ITempDataProvider TempDataProvider {
    get {
        if (_tempDataProvider == null) {
            _tempDataProvider = CreateTempDataProvider();
        }
        return _tempDataProvider;
    }
    set {
        _tempDataProvider = value;
    }
}

protected virtual ITempDataProvider CreateTempDataProvider() {
    return new SessionStateTempDataProvider();
}

How the TempData Provider Gets Used

If you want to tell your controllers to use a different provider, you set it up in your controller’s constructor and you’re good to go. You might have also noticed that the LoadTempData(ControllerContext) function in ITempDataProvider returns an IDictionary, but the TempData property on the controller (actually, ControllerBase to be specific), is of type TempDataDictionary. This is another MVC class that wraps around an IDictionary and provides all the functionality we need from TempData. This is a big class so I won’t go over everything, but there are a couple parts to highlight. First, you can see that the class is marked as being serializable, so that it can properly be put into session:

[Serializable]
    public class TempDataDictionary : IDictionary<string, object>, ISerializable {

Second, there is the Load(ControllerContext, ITempDataProvider) function that uses the specified provider to hydrate the dictionary:

public void Load(ControllerContext controllerContext,
                      ITempDataProvider tempDataProvider) {
    IDictionary<string, object> providerDictionary =
        tempDataProvider.LoadTempData(controllerContext);

    _data = (providerDictionary != null)
        ? new Dictionary<string, object>(
              providerDictionary, StringComparer.OrdinalIgnoreCase) :
        new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);

    _initialKeys = new HashSet<string>(
                      _data.Keys, StringComparer.OrdinalIgnoreCase);

    _retainedKeys.Clear();
}

Similarly, it also has a Save(ControllerContext, ITempDataProvider) function that uses the provider to save out the new dictionary:

public void Save(ControllerContext controllerContext,
                       ITempDataProvider tempDataProvider) {

    string[] keysToKeep =
        _initialKeys
            .Union(_retainedKeys, StringComparer.OrdinalIgnoreCase)
            .ToArray();

    string[] keysToRemove =
        _data
            .Keys
                .Except(keysToKeep, StringComparer.OrdinalIgnoreCase)
                .ToArray();

    foreach (string key in keysToRemove) {
        _data.Remove(key);
    }

    tempDataProvider.SaveTempData(controllerContext, _data);
}

The only part left is figuring when in the pipeline TempData gets load, and then when it gets saved out again. The answers to both are found in the ExecuteCore() method in Controller. This method gets called by MVC to invoke the current action. In order, it loads TempData, then executes the current action, then saves out the new dictionary:

protected override void ExecuteCore() {
    PossiblyLoadTempData();

    try {
        string actionName = RouteData.GetRequiredString("action");

        if (!ActionInvoker.InvokeAction(ControllerContext, actionName)) {
            HandleUnknownAction(actionName);
        }
    }
    finally {
        PossiblySaveTempData();
    }
}

ASP.NET MVC 2 introduced the concept of RenderAction, where you could call out from a view to another controller action and render it within that view. If you do this, the child action actually shares TempData with the parent request. I have found this useful in passing something down to a child request to avoid having to redo a database call for something needed by both the parent and the child. This logic is part of the PossiblyLoadTempData() and PossiblySaveTempData() functions referenced in ExecureCore():

internal void PossiblyLoadTempData() {
    if (!ControllerContext.IsChildAction) {
        TempData.Load(ControllerContext, TempDataProvider);
    }
}

internal void PossiblySaveTempData() {
    if (!ControllerContext.IsChildAction) {
        TempData.Save(ControllerContext, TempDataProvider);
    }
}

Those are the highlights of how TempData works under the hood, and how you can plug in a different provider to tailor the behavior to what you want. You can also find references to it outside of the controller in other places where you have access to TempData, such as ViewContext, ViewPage, etc. As of right now the session provider is the only one in the main assembly. The MvcFutures assembly includes the CookieTempDataProvider class which provides cookie-based TempData storage.

A MongoDB TempData Provider

I think we’ve looked at enough ASP.NET MVC code now, so let’s try writing a custom provider. For this example I’m going to store the data in a MongoDB collection. Now, keep in mind that this example is meant to show how to implement a custom provider, so I’m not trying to make a case that you should store your TempData in MongoDB. For this example I’m going to use the MongoDB-CSharp driver.

First, let’s define the model object that we’re going to store in MongoDB.

public class MongoTempData
{
    public string SessionIdentifier { get; set; }

    public string Key { get; set; }

    public object Value { get; set; }
}

Now we can define our TempData provider to store that model. To avoid sending a user someone else’s TempData, we’ll need a way of uniquely identifying users. Since this is a crude demo, I’ll just use the user’s host address. Obviously, don’t do this in production code.

public class MongoTempDataProvider : ITempDataProvider
{
    private string _collectionName;
    private string _databaseName;

    public MongoTempDataProvider(string databaseName, string collectionName)
    {
        _collectionName = collectionName;
        _databaseName = databaseName;
    }
}

Now for the function for loading data from the collection. Since I’m not specifying the hostname or port for the database, it assumes a default of localhost and 27017. Different values can be provided via the contructors to the Mongo object.

public IDictionary<string, object> LoadTempData(ControllerContext controllerContext)
{
    var tempDataDictionary = new Dictionary<string, object>();

    using (Mongo mongo = new Mongo())
    {
        mongo.Connect();

        IMongoCollection<MongoTempData> collection =
            mongo
                .GetDatabase(_databaseName)
                .GetCollection<MongoTempData>(_collectionName);

        IEnumerable<MongoTempData> tempData = collection.Find(item =>
            item.SessionIdentifier ==
                controllerContext.HttpContext.Request.UserHostAddress
        ).Documents;

        foreach (var tempDataItem in tempData)
        {
            tempDataDictionary.Add(tempDataItem.Key, tempDataItem.Value);

            collection.Remove(tempDataItem);
        }
    }

    return tempDataDictionary;
}

That will connect to the database and read in any TempData that is queued up for the current user. Once an item is read into the dictionary it gets removed from the collection, to make sure no other requests can get it.

Now, the save method:

public void SaveTempData(ControllerContext controllerContext,
                                    IDictionary<string, object> values)
{
    using (Mongo mongo = new Mongo())
    {
        mongo.Connect();

        IMongoCollection<MongoTempData> collection =
            mongo
                .GetDatabase(_databaseName)
                .GetCollection<MongoTempData>(_collectionName);

        IEnumerable<MongoTempData> oldItems =
            collection.Find(item =>
                item.SessionIdentifier ==
                    controllerContext.HttpContext.Request.UserHostAddress
            ).Documents;

        foreach (var tempDataItem in oldItems)
        {
            collection.Remove(tempDataItem);
        }

        if (values != null && values.Count > 0)
        {
            collection.Insert(
                values.Select(tempDataValue =>
                    new MongoTempData
                    {
                        SessionIdentifier =
                            controllerContext.HttpContext.Request.UserHostAddress,
                        Key = tempDataValue.Key,
                        Value = tempDataValue.Value
                    }
                )
            );
        }
    }
}

That will clear out any old data in the dictionary and replace it with the new values. That’s all the code required for the provider, so now we just need to plug it into the controller. We’ll create a base controller class that our controllers will inherit from, to avoid having to specify the TempDataProvider in every controller.

public abstract class MongoControllerBase : Controller
{
    public MongoControllerBase()
    {
        TempDataProvider = new MongoTempDataProvider("test", "MongoTempData");
    }
}

Next we’ll define a test controller with two actions. The first action will insert some data into TempData, and the second will print out the contents of TempData. Remember that the controller needs to inherit from our base controller in order to use our custom provider. If you don’t, it will default to using the session provider.

public class HomeController : MongoControllerBase
{
    public ActionResult Index()
    {
        TempData["CurrentDateTime"] = DateTime.Now;
        TempData["MeaningOfLife"] = 42;

        return Content("TempData Updated");
    }

    public ActionResult ReadTempData()
    {
        return View();
    }
}

Here’s our view for ReadTempData:

Contents of TempData:

<br />
<br />

<% foreach (var tempDataItem in TempData)
   { %>

    Key: <%: tempDataItem.Key %>; Value: <%: tempDataItem.Value %>
    <br />

<% } %>

If you fire up the application, you should see text that says “TempData Updated”. Now if you hit /Home/ReadTempData, you should see something that looks like:

Contents of TempData:

Key: CurrentDateTime; Value: 7/14/2010 10:52:45 PM
Key: MeaningOfLife; Value: 42

If you refresh the page, you will see that the contents of TempData are now empty.

For me, this was one big reminder that you should know exactly how something works before making assumptions about it. Since ASP.NET MVC is open source, it was very easy to load up the solution and poke around under the hood and see precisely how it behaves.

One of the new features introduced in C# 4.0 is the dynamic keyword. So far I haven’t had much use for it, but lately I’ve discovered that it can be very useful when designing ASP.NET MVC views. It also has uses when interacting with COM APIs and other dynamic languages, but I’m going to focus on its use in MVC.

If you’re using .NET 4.0 and ASP.NET MVC 2, and go to add a new view that is not strongly typed, you might notice that the first line will look like this:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>

The thing to pay attention to here is that by default, non-strongly typed views now use a dynamic model by default. As with any use of dynamic you lose the compiler’s type checking in your view (if you’re not compiling your views I would recommend doing so), and your intellisense of course. That said, you do gain quite a bit of freedom when you only have to worry about the properties of the model, rather than the specific type.

Let’s use a very simple example to demonstrate a cool use of dynamic view models with a partial view. We will define a partial view that displays today’s date, and can take in a set of options about what aspects of the date to display. The options class is defined as:

public class DateDisplayOptions
{
    public bool ShowYear { get; set; }

    public bool ShowTime { get; set; }
}

Then we have the partial defined like this, using the options class as its view model:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<DynamicViewSample.Models.DateDisplayOptions>" %>

<%: DateTime.Now.ToString("MMMM d") %>

<% if (Model.ShowYear)
   { %>
    <%: DateTime.Now.ToString(", yyyy")%>

<% } %>

<% if (Model.ShowTime)
   { %>

    <%: DateTime.Now.ToShortTimeString() %>

<% } %>

That will use the options to format today’s date and time appropriately. Now let’s say that we wanted to make it so that if you don’t pass an options object to the partial, it uses some default values. First, we add a constructor to DateDisplayOptions to set default values:

public DateDisplayOptions()
{
    ShowYear = true;
    ShowTime = false;
}

Next, we have to tell the view to allow for receiving a null view model:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<DynamicViewSample.Models.DateDisplayOptions>" %>
<%@ Import Namespace="DynamicViewSample.Models" %>

<%
    DateDisplayOptions options = Model ?? new DateDisplayOptions();
%>

<%: DateTime.Now.ToString("MMMM d") %>

<% if (options.ShowYear)
   { %>

    <%: DateTime.Now.ToString(", yyyy")%>

<% } %>

<% if (options.ShowTime)
   { %>

    <%: DateTime.Now.ToShortTimeString() %>

<% } %>

Now passing in a null view model will display the year but not the time. However, this only gets us part of the way there. When using the RenderPartial method, not explicitly supplying a model to the partial will automatically send the model of the calling page. Obviously that will cause type casting problems when the calling page has a view model that is not DateDisplayOptions, so this is where the dynamic keyword comes to the rescue. We can change the partial to use the dynamic type, and then check for the type ourselves when casting:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<dynamic>" %>
<%@ Import Namespace="DynamicViewSample.Models" %>

<%
    DateDisplayOptions options = (Model as DateDisplayOptions) ?? new DateDisplayOptions();
%>

With that change, the partial will not care what type of model gets sent to it, but if it is not a DateDisplayOptions it will use a new instance with the default options instead. Let’s throw together a quick view to test everything out:

<p>
    <% Html.RenderPartial("ShowToday"); %>
</p>
<p>
    <% Html.RenderPartial("ShowToday", new DateDisplayOptions { ShowTime = false, ShowYear = false }); %>
</p>
<p>
    <% Html.RenderPartial("ShowToday", new DateDisplayOptions { ShowTime = true, ShowYear = true }); %>
</p>

That gives us the following output, which behaves exactly like we wanted:

There are certainly a lot more uses out there for the dynamic keyword, but this is one example I stumbled upon where it came in very useful.

One of the really cool new features in ASP .NET MVC 2 is templated helpers. The basic idea is that you can define a template for either displaying or editing a particular data type, and it will be used by default when displaying or editing that type. This allows you to define the behavior once, and then you don’t need to worry about it in every view you write thereafter. In this post I’ll go over how to use templated helpers to handle both a built-in type, DateTime, as well as a custom type which will demonstrate using a custom model binder.

If you haven’t already done so, I suggest reading through Brad Wilson’s series on templated helpers to give you a good idea of the basics, which I will briefly touch on but not in much detail.

DateTime

First we’ll take a look at the simple case. Let’s say you have a view model that contains a DateTime property:

public class DateTestViewModel
{
    [DisplayName("Birth date")]
    public DateTime DateOfBirth { get; set; }
}

When we display a form for that view model, by default MVC will give you a text box for editing the date. Obviously this isn’t a very user-friendly way to edit a date, so let’s use progressive enhancement to spruce it up with a jQuery UI date picker. Since we’ll want to do this globally across the site, this is a perfect scenario to use a templated helper. For the sake of this demo I’ll keep everything contained in a single view, just to keep things simple. Here is the view code for displaying the editor for the date:

<% using (Html.BeginForm())
   { %>
    <p>
        <%= Html.LabelFor(model => model.DateOfBirth) %>:
        <br />
        <%= Html.EditorFor(model => model.DateOfBirth) %>
    </p>
    <p>
        <input type="submit" value="Submit" />
    </p>
<% } %>

To start, we create a folder under Views/Shared called EditorTemplates. Creating it under Shared allows any view to make use of the templates inside of it. If you want to limit it to a single set of views, you can put the folder inside that view folder. In that folder, let’s create a new view user control that looks like this, named DateTime.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<System.DateTime?>" %>

<%= Html.TextBox("", (Model.HasValue ? Model.Value.ToString("MMMM d, yyyy") : string.Empty), new { @class = "date" }) %>

All we’re doing is creating a textbox for the model, which is a nullable DateTime, and assigns it the class of “date.” Now with jQuery we can quickly attach a date picker to any text input with that class:

$(document).ready(function()
{
    $("input:text.date").datepicker(
    {
        dateFormat: "MM d, yy"
    });
});

And that’s it! Now any time you create an editor for a DateTime property, you’ll get a slick date picker.

SimpleDate

Now let’s say you want to do this with some custom types you have. Can you still use templated helpers to define your views and editors? Of course you can! The only difference is that now you also need to tell MVC how to bind the form input to an object. Continuing with the date theme, let’s implement a simpler version of the date, where you simply want to select a month and a year, leaving out the day of the month. Here’s the class definition for SimpleDate:

public class SimpleDate
{
    [Range(1, 12)]
    public int Month { get; set; }

    [Range(1, 9999)]
    public int Year { get; set; }

    public SimpleDate()
    {
    }

    public SimpleDate(DateTime date)
        : this(date.Year, date.Month)
    {
    }

    public SimpleDate(int year, int month)
    {
        Year = year;
        Month = month;
    }

    public DateTime ToDate()
    {
        return new DateTime(Year, Month, 1);
    }
}

We'll also add it to our view model:

[DisplayName("Billing month")]
public SimpleDate BillingMonth { get; set; }

As well as add it to the view:

<p>
    <%= Html.LabelFor(model => model.BillingMonth) %>:
    <br />
    <%= Html.EditorFor(model => model.BillingMonth) %>
</p>

While we’re at it, let’s define a simple template for it, in the same folder as the last one, called SimpleDate.ascx:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<TemplatedHelpers.Models.SimpleDate>" %>
<%@ Import Namespace="TemplatedHelpers.Extensions" %>

<%= Html.MonthDropDownListFor(model => model.Month, Model.Month) %>

<%= Html.YearDropDownListFor(model => model.Year, Model.Year) %>

Astute readers will have noticed that I used a couple custom extension methods in there for creating the drop down lists. I wrote them up as a quick example for this demo, so while they are not perfect, they get the idea across since that isn’t the focus of this post. Here is the code I have for those functions:

public static class HtmlHelperExtensions
{
    private static string[] _months =
    {
        "January", "February", "March", "April", "May",
        "June", "July", "August", "September", "October",
        "November", "December"
    };

    private static IEnumerable<SelectListItem> getMonthListItems(int? selectedMonth)
    {
        var monthList = new List<SelectListItem>();

        for (int i = 0; i < _months.Length; i++)
        {
            monthList.Add(new SelectListItem
            {
                Text = _months[i],
                Value = (i + 1).ToString(),
                Selected = (selectedMonth == (i + 1))
            });
        }

        return monthList;
    }

    private static IEnumerable<SelectListItem> getYearListItems(int? selectedYear)
    {
        var yearList = new List<SelectListItem>();

        for (int i = 2006; i <= DateTime.Now.Year; i++)
        {
            yearList.Add(new SelectListItem
            {
                Text = i.ToString(),
                Value = i.ToString(),
                Selected = (selectedYear == i)
            });
        }

        return yearList;
    }

    public static MvcHtmlString MonthDropDownListFor<TModel, TProperty>(this HtmlHelper<TModel> htmlHelper, Expression<Func<TModel, TProperty>> expression, int? selectedMonth)
    {
        return htmlHelper.DropDownListFor(expression, getMonthListItems(selectedMonth));
    }

    public static MvcHtmlString YearDropDownListFor<TModel, TProperty>(this HtmlHelper<TModel> htmlHelper, Expression<Func<TModel, TProperty>> expression, int? selectedYear)
    {
        return htmlHelper.DropDownListFor(expression, getYearListItems(selectedYear));
    }
}

So now we have a custom type and the template for editing it, but if you try to post the form you’ll see that you lose any value you have set on it. Why is this? By default, MVC doesn’t know how to bind the form data. To fix that, we can create our own model binder class, which extends the System.Web.Mvc.DefaultModelBinder class:

public class SimpleDateModelBinder : DefaultModelBinder
{
    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        int month = getValue<int>(bindingContext, "Month").Value;
        int year = getValue<int>(bindingContext, "Year").Value;

        return new SimpleDate(year, month);
    }

    private Nullable<T> getValue<T>(ModelBindingContext bindingContext, string key) where T : struct
    {
        if (string.IsNullOrEmpty(key))
        {
            return null;
        }

        ValueProviderResult result = bindingContext.ValueProvider.GetValue(bindingContext.ModelName + "." + key);

        if (result == null && bindingContext.FallbackToEmptyPrefix)
        {
            result = bindingContext.ValueProvider.GetValue(key);
        }

        if (result == null)
        {
            return null;
        }

        return (Nullable<T>)result.ConvertTo(typeof(T));
    }
}

There are a lot of extension points you can tie into with model binders, but here we’ll just keep things as simple as possible. Luckily, that’s all we really need. The getValue() function is inspired by a similar post by Scott Hanselman, and looks through the binding context for the provided key and type, and returns the value if it finds it. Since the keys here are coming from form data, they will be in the form of PropertyName.Month and PropertyName.Year. The BindModel() function grabs these values for the current model being bound, and returns a new SimpleDate based on it.

One last thing to do here, and that is to tell MVC to use that model binder when it encounters SimpleDate. Open up global.asax, and add this into the Application_Start handler:

ModelBinders.Binders.Add(typeof(SimpleDate), new SimpleDateModelBinder());

Need some proof that it works? Of course you do. Let’s add a little bit of code to the view and controller to stuff the values into ViewData when it POSTs, and then display them in the view. Here is our controller action:

[HttpPost]
public ActionResult Index(DateTestViewModel viewModel)
{
    ViewData["DateOfBirth"] = viewModel.DateOfBirth;
    ViewData["BillingMonth"] = viewModel.BillingMonth;

    return View(viewModel);
}

Then in the view we will display it, when it’s there:

<p>
    <% if (ViewData["DateOfBirth"] != null)
       { %>

        DOB: <%= ViewData["DateOfBirth"] %>
        <br />

    <% } %>

    <% if (ViewData["BillingMonth"] != null)
       { %>

        Billing Month: <%= ((TemplatedHelpers.Models.SimpleDate)ViewData["BillingMonth"]).ToDate() %>
        <br />

    <% } %>
</p>

Now when you submit the form, you should see the date values for both date fields on the page displayed at the bottom.

Now we have a slick date picker for when we need to choose a specific date, and a nice option for picking a month and year, all thanks to MVC templated helpers.

One of the many nice things they have added in MVC 2 is model/view model validation on both the client and server side. I won’t go into the basics here since they have been covered extensively by others. However, recently I was adding validation to require a value for a hidden field on a form, and found that the default validation functionality just didn’t work on the client side for a hidden field. Here I will go over how I added some custom validation to allow me to do it.

While it might sound weird to validate a hidden field, something a user will never directly interact with, in this age of complex interfaces built in JavaScript it’s easy to imagine a scenario where a series of interactions leads to storing some kind of value in a hidden field. If that end value is something that is required, it’s only natural that that should be enforced by the model.

First, let’s start by defining a very simple view model for the form:

public class DemoForm
{
    [Required(ErrorMessage = "You must enter a name")]
    public string Name { get; set; }
}

It just defines a single property for storing a name. Now we can define a very basic view that is strictly typed to that view model. Here is the code for setting up the form:

<% using (Html.BeginForm())
{ %>

    <%= Html.HiddenFor(model => model.Name) %>

    <p>
        <%= Html.ValidationMessageFor(model => model.Name) %>
    </p>

    <input type="submit" value="Submit" />

<% } %>

If you run the page now, you will get correct server-side validation, but nothing on the client. To get client validation in MVC, we need to tell the page to enable client validation. To do that, call this before starting the form:

<% Html.EnableClientValidation(); %>

You will also need some JavaScript references to these files, which are included by default in any new MVC project:

<script type="text/javascript" src="<%= ResolveUrl("~/Scripts/MicrosoftAjax.js") %>"></script>
<script type="text/javascript" src="<%= ResolveUrl("~/Scripts/MicrosoftMvcAjax.js") %>"></script>
<script type="text/javascript" src="<%= ResolveUrl("~/Scripts/MicrosoftMvcValidation.js") %>"></script>

Now if you reload the page, client validation still isn’t working. Why not? After digging through the Microsoft validation scripts a bit, I found that the Required validator ignores hidden fields altogether in JavaScript. We could change it from being a hidden field to a text field and the same code would work as expected, but that’s not what we want to do.

As it turns out, they made it rather simple to extend the built-in validation with your own custom rules. First, we’ll define the attribute class, so that it can be added as a decorator to a property the same way the other validators work. In this case, since the Required attribute actually works fine on the server side, our class will extend that and do nothing else. This way we can provide the client side functionality and rely on the existing server validation.

public class HiddenRequiredAttribute : RequiredAttribute
{
}

Now that we have the attribute, we need a validator that uses it. To do that, we extend the DataAnnotationsModelValidator class, and tell it to use the attribute we just defined:

public class HiddenRequiredValidator : DataAnnotationsModelValidator<HiddenRequiredAttribute>
{
    private string _errorMessage;

    public HiddenRequiredValidator(ModelMetadata metaData, ControllerContext context, HiddenRequiredAttribute attribute)
        : base(metaData, context, attribute)
    {
        _errorMessage = attribute.ErrorMessage;
    }

    public override IEnumerable<ModelClientValidationRule> GetClientValidationRules()
    {
        var rule = new ModelClientValidationRule
        {
            ErrorMessage = _errorMessage,
            ValidationType = "hiddenRequired"
        };

        return new[] { rule };
    }
}

The important part to notice here is where we set the ValidationType to “hiddenRequired.” This is the unique identifier we define for referencing our validator in JavaScript. Remember it, because you’re going to need it later.

So now we have an attribute, and a validator for it. Next up, we need to register our validator in the application’s Application_Start function:

DataAnnotationsModelValidatorProvider
    .RegisterAdapter(typeof(HiddenRequiredAttribute), typeof(HiddenRequiredValidator));

Now let’s switch the view model’s Name property to use the new HiddenRequired attribute instead of the Required one we had before:

public class DemoForm
{
    [HiddenRequired(ErrorMessage = "You must enter a name")]
    public string Name { get; set; }
}

All that remains is to put in some JavaScript code to handle the validation. I’ll show the code here, and then discuss it. Since this is a contained demo, I will add the code directly to the view.

Sys.Mvc.ValidatorRegistry.validators["hiddenRequired"] = function(rule)
{
    return function(value, context)
    {
        if (value)
        {
            return true;
        }

        return rule.ErrorMessage;
    }
};

If that code looks simple, that’s because it is. Since we’re only validating that the field has some kind of value, that is all we need to check for. The reason that the return function is wrapped in another function is to allow for adding more complex logic before the return function if needed. For this example, it isn’t needed.

Now if you reload the page you will get the client-side validation we were aiming for, triggered by the submit button. Always remember that client-side validation is just there for improving the user experience, and is no substitute for server validation.