Kevin Hoffman

When we all build websites, usually we're concerned with figuring out how we're going to get the major entities into the view. We want to know how we're going to handle the shopping cart or how we're going to get the customer record onto the page, etc. But, one of the little details that almost always comes back to bite us in the ass is the use of reference data.

Reference data is data that rarely changes, is frequently queried, and shows up in multiple places throughout the application. This might be anything from the list of companies currently trading on a particular stock market if you're building a financial web application or things like the list of countries, states, cities, counties, tax rules, and shipping tables if you're doing fulfillment of orders online.

The problem is we rarely think about reference data ahead of time, so what usually happens is our strategy for handling reference data becomes an ugly pile of spaghetti and we have some controls doing their own queries to get reference data and some pages doing it and some services - it's a mess.

It would be awesome if we could have our controller methods declare ahead of time what reference data the view is going to need and then the view will simply have that data when it renders - completely abstracting the manual fetching of reference data for dropdownlists and other lookups. This centralization of reference data handling also gives us the ability to control the cache lifetimes of reference data items individually.

Thankfully ASP.NET MVC lets us do this easily. All we have to do is create our own action filter attribute. For example, let's say we've got a Customer controller and we're building the Edit(int id) method. Our customer view model objects are normalized enough so that they have IDs on them for country, customer type, and membership type (totally contrived examples, don't diss my domain knowledge of CRMs...). A sample edit method might look like this:

[RequireReferenceData(ReferenceDataKey = ReferenceDataKeys.Countries)]
[RequireReferenceData(ReferenceDataKey = ReferenceDataKeys.CustomerTypes)]
[ReqiureReferenceData(ReferenceDataKey = ReferenceDataKeys.MembershipTypes)]
public ActionResult Edit(int id)
{
    Customer cust = customerRepository.GetCustomerByKey(id);
    return View(cust);
}

The beauty of this approach is that anyone reading your code will immediately know that the view being rendered is going to depend on having 3 different types of reference data lists made available, as well as the core Customer object itself. Compare how easy this is to read and maintain to a classic .ASPX page where you might have the countries lookup being loaded by a custom dropdown box and the customer types lookup being loaded by the page and the membership types being loaded by yet another pile of spaghetti elsewhere.

To create the RequireReferenceDataAttribute class, all you need to do is inherit from ActionFilterAttribute and override the OnExecuting method. In this method you would just fetch the reference data and store it in the ViewData dictionary like this:

context.Controller.Model.ViewData[ReferenceDataKey] = (data fetched from elsewhere...);

And then in your view you can do something like this:

<%= Html.DropDownList("CustomerTypeId", 
(IEnumerable<SelectListItem>)ViewData[ReferenceDataKeys.CustomerTypes]) %>

And you're all set. The main moral of this story is to never underestimate the power of action filters. With ASP.NET MVC, if you want your intent to be more declarative and you want your code to be more readable, chances are you're only a few lines of code away from where you want to be.