Craig Shoemaker posted a blog entry yesterday, and point number six was about using a custom attribute to ease QueryString pains.  At my current job I work with ASP.NET WebForms, and I knew exactly what he was talking about.  I thought this was an awesome idea, and followed his link to a VB article on code project.  I converted the VB code to C#, and made some slight changes.

The Goal

Eliminate “keyboard slapping” and provide some robust functionality at the same time.  In other words, we’re trying to solve the following problems:

1. Try to eliminate the need to access Request.QueryString directly.
2. Try to make the implementation as streamlined as possible.
3. Account for some possible use cases like:
   • Special Parameter Names
   • Synonymous Parameter Names

Out With The Old

As Craig pointed out in his blog, we’ve all written the same mindless QueryString code over and over.  It always amounts to the same boiler plate code, which involves indexing into the Request.QueryString object using a string key and safeguarding the entire operation.  Don’t repeat yourself.

Would become:

AutoValueAttribute

I started with an abstract base class for this implementation.  The idea is that the attribute will have keys, and a way to get a value from those keys.  The idea behind using an abstract base is that we may implement other versions of the AutoValueAttribute later on.

The QueryStringValue Attribute

Any property we wish to set from a QueryString parameter can be decorated with a QueryStringValue attribute.  The implementation is simple, supporting three specific use cases.  This attribute just holds onto values that we can use for processing later.

I expanded on the concept of Keys while converting the VB code.  It originally used a string property named QueryStringParameter.  While this was straight forward, I thought it might be beneficial to build in the ability to handle many parameter names by using a list instead.  A simple use case is changing the parameter name, but wishing to maintain backwards compatibility.

The default constructor doesn’t specify a name.  Instead, the target property’s name will be used as the QueryString parameter key.  A second constructor accepts a single string.  The last constructor accepts an array of strings.  In this case, the first match is the one that will be used.

Calling the GetValue method will iterate through the list of keys, indexing into Request.QueryString until it finds a value.  There is one important caveat to be aware of, and that is if the default constructor was used, the list of keys will be empty.  If only attributes knew exactly which property they were decorating, it wouldn’t be a problem.  The code that consumes this method must add the property name if the attribute contains no other keys (more on that shortly).

Processing The Attributes Via Reflection

In order to make this widely available in an ASP.NET application, I created the processing method as a generic extension method.  The method is called ProcessAttributes.  It uses a constraint to limit it to System.Web.UI.Control objects.

BindingFlags are used to get the properties of the Page.  Then, we iterate through each one.  Using the first QueryStringValueAttribute of each property,  we proceed to get the QueryString value, and set the property.

As previously noted, there is a caveat for calling the GetValue method.  It iterates the attribute’s Keys property until it can get a value out of the QueryString.  If no key was specified in the attribute constructor, it will have a Keys.Count of 0.  In this case, we need to add the property’s name to the list of Keys.

The the SetField method attempts to convert the value to the property’s data type.  There’s a strong chance that this conversion can fail.  While this is probably the most arguable aspect of the whole endeavor, I think that validation is not necessary at this point, and would be better suited for later in the life cycle of the page.  The main goal of this code is to set properties on the page to values in the QueryString.  It seems a little silly to absorb an exception, but it was meant to keep the attribute from getting in your way.

Conclusion

The barrier to entry is really small for making this feature completely streamlined.  I created a new class to derive my Pages from, called PageBase (creative, right?).  It descends from System.Web.UI.Page, and overrides OnPreInit.

By calling ProcessAttributes in OnPreInit, derived classes get this functionality almost completely for free.  Even if you find a need to override OnPreInit in a descending class, base.OnPreInit(e) will keep that going.  The nice part about all of this is how it finally works:

Using this approach to QueryStrings greatly reduces the amount of code you need to write each time a property needs to access the QueryString.  It’s robust because it supports multiple keys, and even works against public and protected properties.  It does its best to stay out of your way while you’re coding, and hopefully shaves off a few keystrokes here and there.

Going The Extra Mile

Craig pointed out that there are other possible uses for this approach, like Form Elements, Cache and Session.  I have looked at trying this out, but found it to be much more difficult.  Things get hairy when you need to save values.  I played with the idea of a [SessionValue] attribute, and even had some success.  I could provide an identical experience to the [QueryStringValue] attribute, where values are automatically assigned.  The problem is that Session variables often change over the course of a request.  If you’re using auto properties, the value just sits there.  That’s where I came up with a PersistableValueAttribute, deriving from AutoValueAttribute.  It added to the AutoValueAttribute functionality, because it provided a Persist method for saving off the value.  I tried to use this in the OnPreRenderComplete event, and it worked.  So it worked, what’s the problem?

Sometimes it is unavoidable, but you just have to tuck your ego in your back pocket and do what you have to do.  The situation I’m talking about is when the request comes in, you change a session variable, more code runs, and then other code uses the same session variable (knowing that it was changed) during the same request.  In the effort I described in the previous paragraph the [SessionValue] property isn’t persisted until the very last second.  That creates a problem when another code depends on that value before it’s persisted.  Oops.  Added complexity isn’t very fun.  I haven’t given up on the thought, but it’s a problem for another day.

I must say that being able to use the Routing engine in ASP.NET MVC is liberating.  In the traditional web model, your browser is making a request for a file on some remote web server.  The server looks for that file, processes it, and makes a response.  This model works great, but what if you don’t want “.aspx” on the end of your Url?  Beyond that, relative paths on the server can take away from any readability your Urls may have had.  Ever tried explaining query string parameters to the average user?  Painful.

Routing isn’t a new thing by any means, but has recently become a reality in the world of .NET.  There’s a whole namespace dedicated to it in System.Web.Routing.  It allows you to create cognitive, user friendly, and meaningful Urls.  Time for an example.

Sam is on a project, and his program manager instructs him to create a user profile page for their application.  With some special permission, Sam is able to try out ASP.NET MVC.  Does he start coding at the drop of a hat?  Never.  Ever.  Requirements first!  One of the general requirements says “The average user knows what page the Url represents.”  Sam is a good programmer, so his gut reaction is a question: “How would the user know that a Url points to their own profile?”  He writes out on his whiteboard (because all good programmers write things out on a whiteboard):

Traditional ASP.NET Web Forms Way:

http://localhost:1234/Users/UserProfile.aspx?UserID=1&Username=johncoder
http://localhost:1234/Users/UserProfile.aspx?UserID=1

Ideal Ways in ASP.NET MVC:

http://localhost:1234/Users/1/johncoder
http://localhost:1234/Users/1
http://localhost:1234/Users/johncoder <- Possible naming conflicts, but previous two work fine.

Now that Sam knows how he wants to accomplish his goal.  He fires up Visual Studio and creates a new ASP.NET MVC Web Application.  He uses his company’s existing data access layer, which uses LINQ to SQL classes.  Routes point to Action Methods on Controllers, which means that Sam needs a UsersController:

public class UsersController : Controller
{
    public ActionResult Details(int id)
    {
        UserRepository repository = new UserRepository();
        User user = repository.FindUserById(id);
        return View(user);
    }
}

The Details Action Method finds the target User, and a View for the user model.  By default, it will use “Views\Users\Details.aspx”.  There’s more!

public class MyMvcApplication : System.Web.HttpApplication
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            "Default",
            "{controller}/{action}/{id}",
            new { controller = "Home", action = "Index", id = "" }
        );
    }

    protected void Application_Start()
    {
        RegisterRoutes(RouteTable.Routes);
    }
}

The above code appears in the Global.asax.cs file an MVC application by default.  “Default” is the name being assigned to this given route, and “{controller}/{action}/{id}” is the Url.  The anonymous object in the next line serves as the default values for this route.  Using this route, the Url to a user would look like this:

http://localhost:1234/Users/Details/1

This isn’t quite what he had in mind.  Sam needs to create a new route to facilitate his need.  Here’s what he came up with:

routes.MapRoute(
    "UserProfile",
    "Users/{id}/{username}",
    new { controller = "Users", action = "Details", username = "" }
);

There's a little trickery going on here. Notice that he made no mention of a controller, or even an action method in the Url. Instead, he is taking advantage of the default parameter values by using an anonymous type. Since he didn’t include “{controller}” in his Url, the anonymous object needs to specify which controller to use.  MVC is built to look for "controller" and "action" keywords, and allows you to add your own. In this case, he added "id" and "username" parameters. If the user does not specify an "id" value, the request will not match against this route, and continue searching the RouteCollection until it finds a match.  Since he specified a default “username” as an empty string, the user is not required to enter a username.  The Url in this route has “Users” hard coded into it.  That literally means that the Url has to have “Users” in it.

Another feature of the Routing engine is that it can be used to generate Urls, too.  Sam can change any View in his application to use an HtmlHelper method like so:

<%= Html.RouteLink(user.FullName, "UserProfile", new { id = user.Id, username = user.Username } ) %>

The first parameter is the anchor text. The second is the name of the Route that the engine should use. The properties of the anonymous object are the parameters in the Url.

Don’t you agree that this is much more flexible than relying on the file system to create Urls?  It is my honest opinion that attention to usability details (even as transparent as a Url) produces a professional, high quality product.  By taking advantage of newer features, like the Routing engine, we can escalate our standards to the next level.