The question on Stack Overflow is titled "How do I route images with ASP.Net MVC", but fundamentally the question is really asking "how can I use ASP.Net MVC to re-route URL's to actual physical files, rather than methods of a controller?"

To be clear, lets address the conceptual differences between routing and url rewriting.  Url rewriting takes the requested URL and modifies it before your code ever sees it.  As far as your application is concerned, the client requested the rewritten URL.  All that URL rewriting does is to change one URL into another URL, based on pattern matching.

Routing is a different and much more powerful beast.  The ASP.Net routing engine maps an URL to a "resource", based on a set of routes.  The first route to match the requested URL wins the prize, and sends the request off to the resource it chooses.  For the ASP.Net MVC framework (which uses System.Web.Routing under the hood), a resource is something that can handle the request object, which is always a piece of code.

So where does that leave physical files?  If a request is always parsed by the routing engine and then handed off to some function somewhere, how can we ever route a request for an image to actually return the physical image?

Well, it takes a tiny bit of legwork, but once we're through it, I'm confident you will see the huge advantages that routing has over simple url-rewriting.  We will show the equivalent of url-rewriting by handling a request for an image using an URL that doesn't map to a physical path, but be able to return the image anyway.

Handling the Request

First off, we need to handle the request that we want to re-route to a physical file.  Out of the box, ASP.Net MVC uses an instance of the MvcRouteHandler object to handle every request.  MvcRouteHandler hides all the complexities of taking the requested URL, breaking it down into parts, finding the right controller in your application, instantiating it and passing it all the data it needs.

The end result of MvcRouteHandler is not what we desire. We want to return an image, not instantiate a controller and run a method.   We want to skip dealing with controllers altogether in this case.  So lets create our own route handler that we'll use instead.

To do so, we simply implement IRouteHandler, an interface exposed by ASP.Net MVC that actually inherits from IHttpHandler.  This means that what we're writing is the ASP.Net MVC equivalent of an .ashx file for a webforms app -- we're inserting our own handling module into the ASP.Net pipeline, that will handle the request much closer to the webserver/http level, rather than at the ASP.Net application level.

IRouteHandler only has one method that we need to implement, which is GetHttpHandler().

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Web;
using System.Web.Compilation;
using System.Web.Routing;
using System.Web.UI;

namespace MvcApplication1
{
    public class ImageRouteHandler : IRouteHandler
    {
        public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
            string filename = requestContext.RouteData.Values["filename"] as string;

            if (string.IsNullOrEmpty(filename))
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.StatusCode = 404;
                requestContext.HttpContext.Response.End();
            }
            else
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.ContentType = GetContentType(requestContext.HttpContext.Request.Url.ToString());

                // find physical path to image here.  
                string filepath = requestContext.HttpContext.Server.MapPath("~/test.jpg");

                requestContext.HttpContext.Response.WriteFile(filepath);
                requestContext.HttpContext.Response.End();
            }
            return null;
        }

        private static string GetContentType(String path)
        {
            switch (Path.GetExtension(path))
            {
                case ".bmp": return "Image/bmp";
                case ".gif": return "Image/gif";
                case ".jpg": return "Image/jpeg";
                case ".png": return "Image/png";
                default: break;
            }
            return "";
        }
    }
}

The above IRouteHandler is pretty simple.  Ignoring the GetContentType helper method, there's really only two things happening.  First, we check for a "filename" parameter that got passed in to our handler (more on that in a second).  If it's not there, we return a 404 response.  Otherwise, we attempt to open up the physical file "test.jpg", and stream it to the browser.

Clearly, this should be adapted to your needs by actually using the filename parameter to find the physical files on your system.   But moving on -- how do we invoke this from our MVC app?  And how do we pass in the filename parameter, of which we'd like to reroute to some other physical path?

Routing the Request to the Custom Handler

Well, this is the easy part.  Where you'd normally define your routes in Global.asax, simply use routes.Add(), instead of routes.MapRoute().  Just like this:

routes.Add("ImagesRoute",
                 new Route("graphics/{filename}", new ImageRouteHandler()));

This method of adding our route allows us to specify our custom IRouteHandler, rather than routes.MapRoute(), which by default uses an instance of MvcRouteHandler.  So now, we've defined a route that matches against any requested URL containing "graphics/", and puts the rest of the URL into the "filename" bucket of the RouteDataDictionary, and hands it off to our IRouteHandler.  This is how we pass the filename parameter into our custom route handler -- basically the same way we pass things into controllers, by defining the variables in the route pattern.

We've successfully routed all URL's containing "graphics/", which doesn't physically exist in our web application, and returning "temp.jpg", which could exist anywhere.  With a bit of coding around the file IO, you could return files from anywhere.

And that's pretty much it!  You might be thinking, "this seems like a lot of extra work just to re-route a URL to a physical file that already existed in my web app!".   If you take a step back though, you'll see the power of this approach.  What if you wanted to log every request to the original URL to a special log file?  What if you wanted to also transform the image before returning it?  Perhaps launch a system executable or asynchronously hit a web service?  What if you wanted to…?

In a nutshell, by inserting your own HttpHandlers into the ASP.Net pipeline to handle routed requests, you can code anything that you'd like to happen when a request comes in, rather than just rewriting it to some other URL.

Viewstate and lifecycle events are still very confusing for new ASP.Net programmers. There is no easy way for them to immediately "get it" -- they have to spend the time in the trenches, watching their data disappear on post back, or double-bind, and flail around with building and rendering their own web controls. They have to see the DataGrid spew its html diarrhea and spend hours customizing it. They have to have that client ask them "what the hell is all this javascript, and why are the pages so big?" and figure out just what the heck all that gibberish on their pages are.

Moving up the experience chain, Viewstate and lifecycle events represent a significant amount of design and front-end time on a web application even for those that have been doing it for a while. You have to balance your state management with your html optimization, caching, and application maintainability. Often you have to build your own state-tracking structures or extend existing ones. You have to carefully consider whether to roll your own custom controls or buy third party interfaces and rely on their javascript and state programming (or maybe their support team!) And for very simple "read-only" web sites, viewstate just gets in the way.

So in summary, Viewstate and lifecycle are still be a pain in the butt, and still represent hurdles for new programmers. Years ago, it was worth the annoyances and problems, because you could write strongly typed, object oriented portable code without getting lost in folders and folders of scripted sites. So why might it be dying? Well…

The first item on the agenda is Silverlight. ASP.Net represented significant advantages for writing portable code that was closer to classic desktop programming, as it abstracted out much of the xhtml. But now I've seen web application developers swoon over Silverlight. If their reaction is any indication, and the amount of momentum that Microsoft is putting into WPF, many shops are going to give up programming their internal or non-public projects in ASP.Net and move to Silverlight instead. I'm personally still skeptical about Silverlight's market penetration, as there are many gaps it doesn't fill for content publishers. But it's not a minor consideration.

Second is the new ASP.Net MVC framework. MVC is an old model that's rapidly gaining traction in the web world, and with the introduction of the ASP.Net MVC framework, it is hard to see any clear advantage to the older webforms model. From Scott Guthrie's Introductory MVC post a couple months ago:

To help enforce testability, the MVC framework today does not support postback events directly to server controls within your Views. Instead, ASP.NET MVC applications generate hyperlink and AJAX callbacks to Controller actions -- and then use Views (and any server controls within them) solely to render output. This helps ensure that your View logic stays minimal and solely focused on rendering, and that you can easily unit test your Controller classes and verify all Application and Data Logic behavior independent of your Views.

And finally, we come to REST, another model that is gaining traction. True REST and webforms are mutually exclusive since REST involves heavy reliance on mapping resource locators to known states of an application. This model has lots of advantages for web services and data-based applications, especially in the realms of testing, while ASP.Net Webform applications are often built around one URL for many states, using Viewstate and Session as your state map, which are of course lost between sessions and server restarts.

So long story short… I think we're seeing the beginning of a new paradigm. In 5 years, will anyone still be developing with true ASP.Net Webforms? It will be interesting to see!