Recap: The goal here is to deploy ASP.NET MVC applications to IIS 6, keeping the clean, extensionless URLs (which requires a wildcard map so that all URLs are processed by ASP.NET, or some tricky URL-rewriting), but without incuring the performance penalty of letting static files get processed by ASP.NET. See the previous post for more details.

So, if you can be disciplined and keep all your static content inside your /Content folder, you can use a normal wildcard map at the root level to get ASP.NET MVC to handle all incoming URLs, even without any “filename extensions” in the URLs, but then also disable that wildcard map on the /Content folder and below, allowing those static files to be processed natively by IIS (which performs much better).

How to set it up

First, deploy your application and use a wilcard map as explained before. Next, find out the “identifier” of your application by looking at IIS Manager:

Now, to remove the wildcard map on the /Content subdirectory, open a command prompt, go to c:\Inetpub\AdminScripts, and run:

adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""

… replacing 105364569 with the “identifier” number of your application. (Also, you could replace “Content” with the path to any other directory.)

That does it! Your /Content folder will now bypass the wildcard mapping, and its files will be served natively by IIS.

Alternative

If you don’t like to use adsutil.vbs, you can achieve the same by exploiting what appears to be a bug in IIS Manager. Turn your subdirectory into an application (from its Directory tab, click “Create”). Then edit its script mappings to remove aspnet_isapi.dll. Then go back and “Remove” the application you just created. The metabase’s new ScriptMaps value will be retained, even though the option has now disappeared from the GUI.

This happens because IIS 6 only invokes ASP.NET when it sees a “filename extension” in the URL that’s mapped to aspnet_isapi.dll (which is a C/C++ ISAPI filter responsible for invoking ASP.NET). Since routing is a .NET IHttpModule called UrlRoutingModule, it doesn’t get invoked unless ASP.NET itself gets invoked, which only happens when aspnet_isapi.dll gets invoked, which only happens when there’s a .aspx in the URL. So, no .aspx, no UrlRoutingModule, hence the 404.

I’d say you’ve got four ways around this:

Option 1: Use a wildcard mapping for aspnet_isapi.dll

This tells IIS 6 to process all requests using ASP.NET, so routing is always invoked, and there’s no problem. It’s dead easy to set up: open IIS manager, right-click your app, go to Properties, then Home Directory tab, then click Configuration. Under Wildcard application maps, click Insert (not Add, which is confusingly just above),  then enter C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll for “Executable”, and uncheck Verify that file exists.

Done! Routing now just behaves as it always did in VS2008’s built-in server.

Unfortunately, this also tells IIS to use ASP.NET to serve all requests, including for static files. It will work, because ASP.NET has a built-in DefaultHttpHandler that does it, but depending on what you do during the request, it might use StaticFileHandler to serve the request. StaticFileHandler is much less efficient than IIS natively. You see, it always reads the files from disk for every request, not caching them in memory. It doesn’t send Cache-Control headers that you might have configured in IIS, so browsers won’t cache it properly. It doesn’t do HTTP compression. However, if you can avoid interfering with the request, DefaultHttpHandler will pass control back to IIS for native processing, which is much better.

For small intranet applications, wildcard mappings are probably the best choice. Yes, it impacts performance slightly, but that might not be a problem for you. Perhaps you have better things to worry about.

For larger public internet applications, you may need a solution that delivers better performance.

Update: It turns out that you can disable wildcard maps on selected subfolders, which may give you the best of both worlds.

Option 2: Put .aspx in all your route entries’ URL patterns

If you don’t mind having .aspx in your URLs, just go through your routing config, adding .aspx before a forward-slash in each pattern. For example, use {controller}.aspx/{action}/{id} or myapp.aspx/{controller}/{action}/{id}. Don’t put .aspx inside the curly-bracket parameter names, or into the ‘default’ values, because it isn’t really part of the controller name - it’s just in the URL to satisfy IIS.

Now your application will be invoked just like a traditional ASP.NET app. IIS still handles static files. This is probably the easiest solution in shared hosting scenarios. Unfortunately, you’ve spoiled your otherwise clean URL schema.

Options 3: Use a custom filename extension in all your URL patterns

This is the same as the above, except substituting something like .mvc instead of .aspx. It doesn’t really create any advantage, other than showing off that you’re using ASP.NET MVC.

Just update your route entries as described above, except putting .mvc instead of .aspx. Next, register a new ISAPI mapping: Open IIS manager, right-click your app, go to Properties, then Home Directory tab, then click Configuration. On the Mappings tab, click Add, then enter C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll for “Executable”, .mvc (or whatever extension you’re using) for “Extension”, and uncheck Verify that file exists. Leave Script engine checked (unless your app has Execute permission) and leave All verbs selected unless you specifically want to filter HTTP methods.

That’s it - you’re now using a custom extension. Unfortunately, it’s still a bit of an eyesore on your otherwise clean URL schema.

Option 4: Use URL rewriting

This is a trick to make IIS think there’s a filename extension in the URL, even though there isn’t. It’s the hardest solution to implement, but the only one that gives totally clean URLs without any significant drain on performance.

Ben Scheirman came up with a great post on this subject, but I’m adapting the technique slightly so as to avoid needing to change my routing configuration in any way. Here’s how it works for me:

1. As an extensionless request arrives, we have a 3rd-party ISAPI filter that rewrites the request to add a known extension: .aspx.

2. IIS sees the extension, and maps it to aspnet_isapi.dll, and hence into ASP.NET

3. Before routing sees the request, we have an Application_BeginRequest() handler that rewrites the URL back to its original, extensionless form

4. Routing sees the extensionless URL and behaves normally.

Since the URL gets un-rewritten in step 3, you don’t have to do anything funny to make outbound URL generation work.

How to do it

First, download and install Helicon’s ISAPI_Rewrite. You can use the freeware edition, version 2, though beware this will affect all the sites on your server. If you need to localize the rewriting to a particular app or virtual directory, you’ll need one of the paid-for editions.

Now edit ISAPI_Rewrite’s configuration (Start -> All programs -> Helicon -> ISAPI_Rewrite -> httpd.ini), and add:

# If you're hosting in a virtual directory, enable these lines,
# entering the path of your virtual directory.
#UriMatchPrefix /myvirtdir
#UriFormatPrefix /myvirtdir

# Add extensions to this rule to avoid them being processed by ASP.NET
RewriteRule (.*)\.(css|gif|png|jpeg|jpg|js|zip) $1.$2 [I,L]

# Normalizes the homepage URL to /
RewriteRule /home(\?.*)? /$1 [I,RP,L]
RewriteRule / /home [I] 

# Prefixes URLs with "rewritten.aspx/", so that ASP.NET handles them
RewriteRule /(.*) /rewritten.aspx/$1 [I]

This excludes known, static files (CSS, GIF etc.), but for the rest, it prefixes the URL with /rewritten.aspx, making ASP.NET kick in. As a bonus, it normalizes any requests for /home to simply / via a 301 redirection, helping out with your SEO. Save this file, and restart IIS (run iisreset.exe).

That’s implemented step 1. Now, to implement step 3, add the following handler to your Global.asax.cs file:

protected void Application_BeginRequest(Object sender, EventArgs e)
{
    HttpApplication app = sender as HttpApplication;
    if (app != null)
        if (app.Request.AppRelativeCurrentExecutionFilePath == "~/rewritten.aspx")
            app.Context.RewritePath(
                app.Request.Url.PathAndQuery.Replace("/rewritten.aspx", "")
            );
}

This detects rewritten URLs, and un-rewrites them. That does it! (Or at least it works on my machine - please share your experiences.)

Now you’ve got clean, extensionless URLs on IIS 6 (and probably on IIS5, though I haven’t tried), without using a wildcard map, and without interfering with IIS’s efficient handling of static files.

Bonus option 5: Upgrade to Windows Server 2008 and IIS 7

Of course, it’s much easier with IIS 7, because it natively supports .NET IHttpModules, so by default you’ll have UrlRoutingModule plugged right into the server, and you don’t have to do anything weird to make it work perfectly.

Download the installer here, and the source here.

Hooray!

There’s such a buzz around the as-yet-unreleased MVC framework - you can hardly move for blog posts, screen casts, sample applications, etc. - but when this thing finally gets released, many developers will benefit from a single, coherent, up-to-date treatment of the entire subject.

My target audience is C# developers with some ASP.NET knowledge, so if you’re in this group, you will (hopefully) find this book contains the right blend of theory, tutorials, and reference material to make you productive, fast. As well as covering the MVC framework in depth, and building a meaty e-commerce application from scratch, you’ll also learn about the relevant architectures, design patterns, open-source tools, and automated testing techniques. Not to mention security issues, deployment guides, and so on…

This hasn’t been a tightly-guarded secret: the book has been available for pre-order on Amazon* for weeks already. If you have any comments or suggestions for things you’d like to see in the book, please email me or leave a comment here.

* At the time of writing this post, not everything on Amazon’s page is entirely accurate and up-to-date - some of the book’s contents are still subject to change.

There have been a couple of great efforts from the community, including Juergen Baeurle’s MVC Validator Toolkit, and Matt Hawley’s MVC UI Validation Framework (now part of MVC Contrib). I wasn’t really satisfied with either, because they take validation out of the domain model and into the application’s UI (no offense guys, what you’ve done is cool).

So, check out my first ever screencast - 6 thrilling minutes of non-stop coding action, in which you get to add both server-side and breathtakingly fit client-side validation to an ASP.NET MVC application, while keeping all the validation rules right in the domain model. Whoo!

For those of you that don’t have time for screencasts (like me, normally), here’s how to get the client-side validation goodness in your ASP.NET MVC application. I’m using Castle Validator for the server-side bits, and Live Validation for the client-side bits, fused into one terrifying alien beast hell-bent on ultimate data purity.

Instructions

1. Download and reference MvcValidator.dll and Castle.Components.Validator.dll (from the Castle project). In your master page, add a reference to the Live Validation script (preferably a local copy of it):

<script src="http://www.livevalidation.com/javascripts/src/1.3/livevalidation_standalone.compressed.js"></script>

2. Add validation attributes to your model object.

public class Person
{
    [ValidateNonEmpty("Please enter a name")]
    public string Name { get; set; }
 
    [ValidateNonEmpty("Please enter an email address")] [ValidateEmail]
    public string Email { get; set; }
 
    [ValidateNonEmpty("Please enter an age")] [ValidateInteger]
    public int? Age { get; set; }
}

3. Drop an Html.ClientSideValidation into your view:

<% using(Html.Form("Home", "SubmitPerson", FormMethod.Post)) { %>
    <p>Name: <%= Html.TextBox("MyPrefix.Name", ViewData.Name) %></p>
    <p>Email: <%= Html.TextBox("MyPrefix.Email", ViewData.Email)%></p>
    <p>Age: <%= Html.TextBox("MyPrefix.Age", ViewData.Age)%></p>
 
    <%= Html.ClientSideValidation(ViewData, s => "MyPrefix." + s) %>
    <%= Html.SubmitButton() %>
<% } %>

4. Strut, pose, be smug. You’re done!

Optional steps:

5. Add server-side validation keyed off the same validation attributes, using Castle Validator’s ValidatorRunner (the screencast shows this in action before the client-side validation).

6. Add CSS rules to get the red/green border effect as shown in the screenshot.

Downloads

• Source code and demo project
• Just the DLL, please!

Thoughts

I’d really love to see something along these lines baked into the official MVC framework, perhaps following Castle’s example of having a pluggable system for emitting Javascript for particular validation checks, so folks could integrate it with client-side validation libraries of their choice. (In my version, I’ve just hard-coded it to work with Live Validator.)

“What about separating presentation from logic??” they’ll cry, and of course you’ll explain the bigger picture of separation of concerns: domain logic from application logic from UI logic, and how MVC adds scope for testability and cleaner code and how foreach loops beat databinding any day, and so on, mercilessly kicking WebForms’s elderly butt.

And of course you’re right. But each time I have to type out view code like this:

<table cellspacing="0">
    <thead>
        <tr>
            <th>ID</th>
            <th>Product</th>
            <th>Category</th>
            <th align="right">Price</th>
            <th></th>
        </tr>
    </thead>
    <tbody>
        <% foreach(var item in ViewData.Products) { %>
            <tr>
                <td><%= item.ProductID %></td>
                <td><%= item.Name %></td>
                <td><%= item.Category %></td>
                <td align="right"><%= item.Price.ToString("c") %></td>
                <td><%= Html.ActionLink("Details", "Show", new { ProductID = item.ProductID }) %></td>
            </tr>
        <% } %>
    </tbody>
</table>

… I can’t help thinking that something’s slightly not right here (and honestly, I try to suppress that dark thought!). Oh don’t get me wrong, I’m a big fan of the new MVC framework, and I’d take it rather than WebForms any day, but software development technology normally progresses like this:

• Old technology: Specify exactly what you want the computer to do
• New technology: Specify what end result you want, but let the computer work out the details

Great examples of the latter bullet point are query languages like SQL or even LINQ, and many of C#’s newer features (e.g. type inference). And how about:

• Classic ASP: Specify exactly what HTML markup you want
• WebForms: Specify what end result you want (e.g. a grid), and let the framework figure out what HTML markup is required
• ASP.NET MVC: Um, specify exactly what HTML markup you want

My experience is that WebForms was a great idea, for its time, but in practice it just didn’t work so well. For demoware, it’s an awesome platform, but try to build a 3-person-year project with it and it will all end in tears (but not tiers).

So, with MVC, we think again and take stock of where we are. HTML is still a real concern, WebForms’s abstraction layer *didn’t* save us from browser incompatibilities, and HTTP is still a stateless protocol. Time for a change of plan, back to basics and all that, but do we really have to go back to writing <TABLE><THEAD><TR><TH>… etc.? It’s not hard, it’s just verbose. Do we need a better DSL for HTML? Is that what alternate view engines could provide?

The framework’s built-in HTML helpers really do help us, but they only produce individual HTML tags, not related groups of tags. Maybe we should add some new ones, e.g. Html.Table, so you could just write:

<%= Html.Table(ViewData.Products, new { cellspacing = 0 })
    .AddColumn("ID", i => i.ProductID)
    .AddColumn("Product", i => i.Name)
    .AddColumn("Category", i => i.Category)
    .AddColumn("Price", i => i.Price.ToString("c"), new { align = "right" })
    .AddColumn("", i => Html.ActionLink("Details", "Show", new { ProductID = i.ProductID }))
%>

In case you do think that’s a good idea, here’s the code needed to implement it. Sorry it’s a bit long, but each method has a few overrides to give you more flexibility in how you supply parameters:

namespace StevenSanderson.Mvc.HtmlHelpers
{
    public static class TableHelper
    {
        public static HtmlTable<T> Table<T>(this HtmlHelper html, IEnumerable<T> data)
        {
            return html.Table<T>(data, null);
        }
        public static HtmlTable<T> Table<T>(this HtmlHelper html, IEnumerable<T> data, object htmlAttributes)
        {
            return html.Table<T>(data, htmlAttributes.ToPropertyList());
        }
        public static HtmlTable<T> Table<T>(this HtmlHelper html, IEnumerable<T> data, IDictionary<string, string> htmlAttributes)
        {
            return new HtmlTable<T> { Data = data, HtmlAttributes = htmlAttributes };
        }
 
        public class HtmlTable<T>
        {
            public IEnumerable<T> Data; 
            public IDictionary<string, string> HtmlAttributes;
            private IList<HtmlTableColumn> columns = new List<HtmlTableColumn>();
 
            public HtmlTable<T> AddColumn(string headerText, Func<T, object> itemText)
            {
                return this.AddColumn(headerText, itemText, null);
            }
 
            public HtmlTable<T> AddColumn(string headerText, Func<T, object> itemText, object htmlAttributes)
            {
                return this.AddColumn(headerText, itemText, htmlAttributes.ToPropertyList());
            }
 
            public HtmlTable<T> AddColumn(string headerText, Func<T, object> itemText, IDictionary<string, string> htmlAttributes)
            {
                columns.Add(new HtmlTableColumn
                {
                    HeaderText = headerText,
                    ItemText = itemText,
                    HtmlAttributes = htmlAttributes
                });
                return this;
            }
 
            private void RenderAttributes(HtmlTextWriter writer, IDictionary<string, string> attribs)
            {
                if (attribs != null)
                    foreach (var attrib in attribs)
                        writer.AddAttribute(attrib.Key, attrib.Value.ToString(), true);
            }
 
            public override string ToString()
            {
                using (StringWriter sw = new StringWriter())
                {
                    HtmlTextWriter writer = new HtmlTextWriter(sw);
 
                    // <TABLE>
                    RenderAttributes(writer, this.HtmlAttributes);
                    writer.RenderBeginTag(HtmlTextWriterTag.Table);
 
                    // Headers
                    writer.RenderBeginTag(HtmlTextWriterTag.Thead);
                    RenderTableRow(writer, HtmlTextWriterTag.Th, col => col.HeaderText);
                    writer.RenderEndTag(); // </THEAD>
 
                    // Rows
                    writer.RenderBeginTag(HtmlTextWriterTag.Tbody);
                    foreach (T row in Data)
                        RenderTableRow(writer, HtmlTextWriterTag.Td, col => col.ItemText(row).ToString());
                    writer.RenderEndTag(); // </TBODY>
 
                    writer.RenderEndTag(); // </TABLE>
                    return sw.ToString();
                }
            }
 
            private void RenderTableRow(HtmlTextWriter writer, HtmlTextWriterTag cellTag, Func<HtmlTableColumn, string> cellValue)
            {
                writer.RenderBeginTag(HtmlTextWriterTag.Tr);
                foreach (var col in columns)
                {
                    RenderAttributes(writer, col.HtmlAttributes);
                    writer.RenderBeginTag(cellTag);
                    writer.Write(cellValue(col));
                    writer.RenderEndTag(); // </TH>
                }
                writer.RenderEndTag(); // </TR>
            }
 
            class HtmlTableColumn
            {
                public string HeaderText { get; set; }
                public Func<T, object> ItemText { get; set; }
                public IDictionary<string, string> HtmlAttributes { get; set; }
            }
        }
 
        private static IDictionary<string, string> ToPropertyList(this object obj)
        {
            return obj == null ? null
                : obj.GetType().GetProperties().ToDictionary(p => p.Name, p => p.GetValue(obj, null).ToString());
        }
    }
}

Note that, to use this, you need to add <%@ Import Namespace=”StevenSanderson.Mvc.HtmlHelpers” %> to the top of your view page (probably changing the namespace to something more suitable for your project), or add the namespace to your web.config in the system.web/pages/namespaces node.

Well yes, actually. Ever since Windows NT 4 we’ve had a notion of I/O Completion Ports (IOCP) which are a mechanism for waiting for I/O to complete without causing thread contention in the meantime. .NET has a special thread pool reserved for threads waiting on IOCP, and you can take advantage of that in your ASP.NET MVC application.

The IHttpAsyncHandler, first introduced in ASP.NET 2.0, splits request processing into two. Instead of handling an entire request in one thread (expensive I/O and all), it first does some processing in the normal ASP.NET thread pool, as per any normal request, then when it’s time for I/O, it transfers control to the I/O thread, releasing the original ASP.NET thread to get on with other requests. When the I/O signals completion (via IOCP), ASP.NET claims another, possibly different thread from its worker pool to finish off the request. Thus, the ASP.NET thread pool doesn’t get ‘clogged up’ with threads that are actually just waiting for I/O.

Adding asynchronous processing to ASP.NET MVC

The MVC framework doesn’t (yet) come with any built-in support for asynchronous requests. But it’s a very extensible framework, so we can add support quite easily. First, we define AsyncController:

public class AsyncController : Controller
{
    internal AsyncCallback Callback { get; set; }
    internal IAsyncResult Result { get; set; }
    internal Action<IAsyncResult> OnCompletion { get; set; } 
 
    protected void RegisterAsyncTask(Func<AsyncCallback, IAsyncResult> beginInvoke, Action<IAsyncResult> endInvoke)
    {
        OnCompletion = endInvoke;
        Result = beginInvoke(Callback);
    }
}

It’s just like a normal Controller, except it manages some internal state to do with asynchronous processing, and has the RegisterAsyncTask() method that lets you manage transitions across the gap between the two halves of IHttpAsyncHandler processing. Note: it doesn’t implement IHttpAsyncHandler itself; that’s the job of the IRouteHandler we have to set up. Unfortunately I had to reproduce most of the code from the framework’s MvcHandler, because I couldn’t just override any individual method and still get at the controller:

public class AsyncMvcRouteHandler : IRouteHandler
{
    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return new AsyncMvcHandler(requestContext);
    } 
 
    class AsyncMvcHandler : IHttpAsyncHandler, IRequiresSessionState
    {
        RequestContext requestContext;
        AsyncController asyncController;
        HttpContext httpContext; 
 
        public AsyncMvcHandler(RequestContext context) 
        { 
            requestContext = context; 
        } 
 
        // IHttpHandler members
        public bool IsReusable { get { return false; } }
        public void ProcessRequest(HttpContext httpContext) { throw new NotImplementedException(); } 
 
        // IHttpAsyncHandler members
        public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
        {
            // Get the controller type
            string controllerName = requestContext.RouteData.GetRequiredString("controller"); 
 
            // Obtain an instance of the controller
            IControllerFactory factory = ControllerBuilder.Current.GetControllerFactory();
            IController controller = factory.CreateController(requestContext, controllerName);
            if (controller == null)
                throw new InvalidOperationException("Can't locate the controller " + controllerName);
            try
            {
                asyncController = controller as AsyncController;
                if (asyncController == null)
                    throw new InvalidOperationException("Controller isn't an AsyncController."); 
 
                // Set up asynchronous processing
                httpContext = HttpContext.Current; // Save this for later
                asyncController.Callback = cb;
                (asyncController as IController).Execute(new ControllerContext(requestContext, controller));
                return asyncController.Result;
            }
            finally
            {
                factory.DisposeController(controller);
            }
        } 
 
        public void EndProcessRequest(IAsyncResult result)
        {
            CallContext.HostContext = httpContext; // So that RenderView() works
            asyncController.OnCompletion(result);
        }
    }
}

It handles requests by supplying an AsyncMvcHandler, which implements IHttpAsyncHandler. Note that during the first half of the processing, i.e. during BeginProcessRequest(), it makes a record of the current HttpContext object. We have to restore that later, during EndProcessRequest(), because we’ll be in a new thread context by then and HttpContext will be null (and that breaks various ASP.NET facilities including WebForms view rendering).

Using AsyncController

It’s now very easy to handle a request asynchronously. Define a route using AsyncMvcRouteHandler, instead of MvcRouteHandler:

routes.Add(new Route("Default.aspx", new AsyncMvcRouteHandler())
{
    Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});

Then set up an AsyncController. In this example, we’re calling an external web service using the WebRequest class and its BeginGetResponse() method. That uses an IOCP, so won’t consume an ASP.NET worker thread while it waits:

public class HomeController : AsyncController
{
    public void Index()
    {
        WebRequest req = WebRequest.Create("http://www.example.com");
        req.Method = "GET";
 
        RegisterAsyncTask(cb => req.BeginGetResponse(cb, null), delegate(IAsyncResult result) {
            WebResponse response = req.EndGetResponse(result);
            // Do something with the response here if you want
            RenderView("Index");
        });
    }
}

And that’s it. The web request gets set up and started in the first half of the async processing model, then the thread gets released to serve other requests. When the web request signals completion, ASP.NET takes a different thread from its pool, and gets it to run the code inside the anonymous delegate, inheriting the request context from the first thread so it can send output to the visitor.

Just remember that you should only use async requests when you’re waiting for some operation on an IOCP. Don’t use it if you just going to call one of your own delegates asynchronously (e.g. using QueueUserWorkItem()) because that will come out of the ASP.NET worker thread pool and you’ll get exactly zero benefit (but more overhead).

… and perhaps even more surprising:

Is there anything Vista can’t do?

1. Treat it as a loosely-typed dictionary, in which case you get no help from intellisense and have to keep writing typecasts all over your views (which is error-prone and ugly):

Customer name: <%= ((Customer)ViewData[”Customer”]).FullName %>

2. Treat it as a specific strongly-typed object - but which type? It’s all very well to pass in one of my domain objects (as in RenderView(”ShowCustomer”, customerRecord)), but the next minute I want to add a status message or something, and the model breaks down.

Jeffrey Palermo came up with a great idea called SmartBag: it solves the problem - at least partially - by supplying an interface like ViewData.Get<CatOwner>() (which returns the first CatOwner object in the collection). This certainly reduces the scope for typos and the need for typecasts. Still, I wasn’t satisfied, because it gets awkward when you have more than one object of a given type (you have to revert to using string keys).

A helpful convention

Fairly soon, I settled down on a convention that seems effective (so far). In the code-behind file for every ViewPage, right at the top, I define a very simple data container object specific to that ViewPage:

public class ShowCatViewData
{
    public string Name { get; set; }
    public int Age { get; set; }
    public bool HasFunnyFace { get; set; }
    public CatOwner Owner { get; set; }
}
 
public partial class ShowCat : ViewPage<ShowCatViewData>
{
}

… and then of course render the view like this:

[ControllerAction]
public void Index()
{
    RenderView("ShowCat", new ShowCatViewData {
        Name = "Moo-moo",
        Age = 6,
        HasFunnyFace = true
    });
}

Now we have strongly-typed ViewData so we get intellisense and no need for typecasts. Because the ShowCatViewData class is specific to the ShowCat view, I don’t mind adding in extra fields (e.g. for status messages or whatever) whenever they’re needed. It doesn’t interfere with my database model.

But what if my controller prefers loosely-typed dictionaries?

Admittedly, sometimes it seems nice to use the dictionary syntax to construct ViewData. You can add fields incrementally, and the controller doesn’t need to know about any particular .NET class specific to the view, like this:

[ControllerAction]
public void Index()
{
    ViewData["Age"] = 25;
    ViewData["HasFunnyFace"] = false;
    if (nameIsKnown)
        ViewData["Name"] = "Frankie"; 
    RenderView("ShowCat");
}

… but you can’t do that if the ViewPage demands a strongly-typed ViewData object, right?

Introducing AutoTypeViewPage<T>

When you derive a ViewPage from AutoTypeViewPage<T>, your ViewPage suddenly gets a little bit smarter.

Just change this:

public partial class ShowCat : ViewPage<ShowCatViewData> { ... }

… to this:

public partial class ShowCat : AutoTypeViewPage<ShowCatViewData> { ... }

and now you can use any of following three syntaxes to send the ViewData, and you’ll get the exact same strongly-typed ViewData in the ASPX page:

Syntax #1: Old-school dictionary

ViewData["Name"] = "Moo-moo";
ViewData["Age"] = 6;
ViewData["HasFunnyFace"] = true;
RenderView("ShowCat");

Syntax #2: Explicitly-typed ViewData object

RenderView("ShowCat", new ShowCatViewData {
    Name = "Moo-moo",
    Age = 6,
    HasFunnyFace = true
});

Syntax #3: Anonymously-typed object

RenderView("ShowCat", new { 
    Name = "Moo-moo", 
    Age = 6, 
    HasFunnyFace = true 
});

How interesting! Show me the code

OK, chill out. It’s very simple:

public class AutoTypeViewPage<TViewData> : ViewPage<TViewData>
{
    protected override void SetViewData(object viewData)
    {
        if ((viewData == null) || (typeof(TViewData).IsAssignableFrom(viewData.GetType())))
            // The incoming object is already of the right type
            base.SetViewData(viewData);
        else
        {
            // Convert the incoming object to a dictionary, if it isn't one already
            IDictionary suppliedProps = viewData as IDictionary;
            if (suppliedProps == null)
                suppliedProps = viewData.GetType().GetProperties()
                                .ToDictionary(pi => pi.Name, pi => pi.GetValue(viewData, null)); 
            // Construct a TViewData object, taking values from suppliedProps where available
            TViewData data = Activator.CreateInstance<TViewData>();
            foreach (PropertyInfo allowedProp in typeof(TViewData).GetProperties())
                if (suppliedProps.Contains(allowedProp.Name))
                    allowedProp.SetValue(data, suppliedProps[allowedProp.Name], null);
            base.SetViewData(data);
        }
    }
}

Final notes

Apparently MonoRail has something vaguely related: DictionaryAdapter. It’s a bit different because what that does is take a pure interface and create a basic implementation via run-time code gen, so you don’t need a concrete implementation of the ViewData class - just an interface for it. If you were clever, you could combine that with the AutoTypeViewPage technique so that arbitrary incoming objects were converted to IMyInterface.

If you have any feedback, you know where to post!

Download helper assembly | Download demo project | Browse source repository

A reminder

In case you’ve missed my other posts about jMVC, it’s a teeny-tiny Javascript library which brings the MVC coding experience into the browser. It doesn’t solve world hunger, but it does make it far easier to build UIs that change dynamically according to data entered or options chosen, without needing any calls to the server (that means you, AJAX). There’s a demo site and a tutorial on CodeProject.com, both based around the ASP.NET flavour.

If you want to use it with ASP.NET, or with Castle MonoRail, you can have the convenience of strongly-typed .NET objects on the server databound (in and out) to a dynamic UI on the client. This post will show how to get the same convenience when using ASP.NET MVC.

Installation

1. Start a new MVC Web Application, or open an existing one.

2. Download the jMVC for ASP.NET MVC package, or build it yourself from the sources. Copy the two DLLs somewhere accessible to your project, and add a reference to them.

3. In your web.config file, add a reference to the jMVCHelper namespace:

Well done, you’re ready to go!

Usage

I’ll copy the same Task List example as used on the CodeProject.com article. We want to add to our MVC application a simple, fully client-side task list editor looking like this:

First, go to the controller that’s going to provide the data. If you just made a new MVC application using the default template, you can use HomeController.cs, and edit it to look like this:

public class HomeController : Controller
{
    private class Task
    {
        public string Name;
        public bool IsCompleted = false;
        public bool HasNotes = false;
        public string Notes = "";
    }
 
    [ControllerAction]
    public void Index()
    {            
        // Supply some initial data to jMVC
        // You'd normally get it from a database, 
	// rather than hard-coding it
        ViewData["tasks"] = new List<Task>() { 
            new Task { Name = "Feed fish", IsCompleted = true }, 
            new Task { Name = "Buy new digital SLR" } 
        };
 
        RenderView("Index");
    }
 
    [ControllerAction]
    public void About()
    {
        // Not really using this, but can leave it in place
        RenderView("About");
    }
}

So, we’ve defined a data structure for our Task objects, and assigned a List of them into the ViewData for the page.

Now, in the corresponding view (Index.aspx, in this case), you can insert the jMVC panel like so:

If you run the application now, you’ll get a weird 404 error because it’s trying to load /Views/jMVC/tasks.jmvc, but you haven’t created this yet. Create a new blank text file at that location. This isn’t a tutorial on jMVC syntax (for that, see this guide, or examine the samples), so just paste in the following:

<% if(model.tasks.length == 0) { %>
    <p>No tasks have been added.</p>
<% } else { %>
    <table border="1" cellpadding="6">
        <thead>
            <tr>
                <th align="left">Task</th>
                <th align="left">Status</th>
                <th align="left"></th>
            </tr>
        </thead>
        <% for(var i = 0; i < model.tasks.length; i++) { %>
            <tr>
                <td>
                    <span style='<%= model.tasks[i].IsCompleted ? "text-decoration:line-through" : "font-weight:bold" %>'>
                        <%= model.tasks[i].Name %>
                    </span>
                </td>
                <td>
                    <label>
                        <input type="checkbox" onclick="<%* function(i) { model.tasks[i].IsCompleted = this.checked } %>" 
                            <%= model.tasks[i].IsCompleted ? "checked" : "" %> />
                        Completed
                    </label>
                    <label>
                        <input type="checkbox" onclick="<%* function(i) { model.tasks[i].HasNotes = this.checked } %>" 
                            <%= model.tasks[i].HasNotes ? "checked" : "" %> />
                        Has notes
                    </label>      
                    <% if(model.tasks[i].HasNotes) { %>          
                        <div><textarea onchange="<%* function(i) { model.tasks[i].Notes = this.value; } %>">
                            <%= model.tasks[i].Notes %></textarea></div>
                    <% } %>
                </td>
                <td>
                    <a href="#" onclick="<%* function(i) { model.tasks.splice(i, 1); } %>"">Delete</a>
                </td>
            </li>
            </tr>
        <% } %>
    </table>
<% } %>
 
Add new task: 
<input type="text" id="NewTaskName" onkeypress="return event.keyCode != 13; /* don't submit form if ENTER is pressed */"/>
<input type="button" value="Add" onclick="<%* function() { addNewTask(model.tasks); } %>" />
 
<% 
    function addNewTask(taskList) {
        var taskName = document.getElementById("NewTaskName").value;
        if(taskName != "")
            taskList[taskList.length] = { Name : taskName, Notes : "" };
    }
%>

I know that looks intimidating, but it’s more interesting than just printing "Hello, world!". If you think about it for a minute, it’s similar syntax as you’d use in any ASP.NET MVC ViewPage, except in this case it’s going to be executed on the client, and Javascript event-handling is baked in. There are simpler examples on the demo site.

Soon I’m going to make the syntax cleaner by adding MVC-style view helper methods, so you’ll be able to write <%= Html.TextBox(…) %> etc., but for now you have to write all the HTML markup yourself.

Getting data back on the server

If you run the app now, you’ll be able to edit the task list. Whee! Isn’t that fun - no server communication at all!

Except there’s no way to post your work back to the server, so change your view to look like this:

 

Note: you need to add a reference to the MVC Toolkit to use this syntax.

Now we’ve added a proper HTML form with submit button. This means that jMVC is going to post a JSON string representing the edited data to the server with the name "myJmvcPanel". To process that on the server, add a new action method to the controller:

[ControllerAction]
public void ReceiveData()
{
    // Retrieve the edited data
    List<Task> result = this.ReadJsonFromRequest<List<Task>>("myJmvcPanel", "tasks");
 
    // Do something useful with it, like save it to the database
    // In this case just prove we've got the updated data
    ViewData["count"] = result.Count;
    RenderView("About");
}

By the way, you’ll need to import the jMVCHelper namespace to use the ReadJsonFromRequest() helper method. Put this at the top of your controller file:

using jMVCHelper;

Hooray, we’re done. The user can add, edit and remove tasks in the browser with no client-server communication, then when they post the form, we get strongly-typed .NET objects to represent the submission.

If you couldn’t be bothered to type those things yourself, you can download the demo project I prepared earlier.