In this post I’ll detail what happens during a request to the default ASP.NET MVC site that you get when you create a new MVC project in Visual Studio.  My goal is to list the major classes involved and how they interact.  There is a lot more that goes on during a request, and I’ve completely skipped action filters.  This is just the highlights.

First, there are some steps that happen at application start:

• The web.config file adds System.Web.Routing.UrlRoutingModule.  During initialization, UrlRoutingModule attaches event handlers for HttpApplication’s PostResolveRequestCache and PostMapRequestHandler events.  These handlers do some magic (using pre-existing extension points in ASP.NET) to ensure that requests in both IIS6 and IIS7, and for various versions of .NET, all wind up in the right place.
• The web.config file also adds MvcHttpHandler.  Requests matching *.mvc are handled with it.  This is also part of the goo that makes MVC work with different versions of IIS and .NET.
• Application_Start().  This HttpApplication event handler is overridden in the Global class (Global.asax.cs).  It calls the RegisterRoutes() method, also defined on the Global class.
  • RegisterRoutes() informs the routing infrastructure which requests to route to which controllers and actions, how to populate action method parameters from the URL, and what the default parameter values are.  It does this by adding Route objects to an ordered collection.

The application is now setup to begin accepting requests.  Here are pseudocode and descriptions for what happens on each request.  Note that wherever you see “httpContext”, the object is actually derived from the HttpContextBase class defined in System.Web.Abstractions.  This avoids the web forms dependency on HttpContext, and allows for code execution and testing outside the context of a web request.

This could use a sequence diagram, and I hope to create one soon.  In the meantime, you can try to follow along in Reflector (or the MVC source if you’ve downloaded it).

• The UrlRoutingModule event handlers do their magic, the result of which is the creation of an MvcHttpHandler object and a call to its ProcessRequest() method.  MvcHttpHandler derives from UrlRoutingHandler, which is part of the routing API and implements IHttpHandler.
• mvcHttpHandler.ProcessRequest():
  • routeData = RouteCollection.GetRouteData(httpContext);
    • In turn, calls route.GetRouteData() on each route in the collection. The collection is whatever we added during RegisterRoutes() at application startup, in order. The first route to return a non-null value wins the request.  RouteData contains the names of the controller and action (both required), along with the values of any other tokens defined in the route URL format.
      • RouteData is important, as it carries request-specific data (e.g., URL token values) that are not present in HttpContext.  The RequestContext object is an aggregation of HttpContext and RouteData, and is available to all later processing of the request.
  • mvcRouteHandler = routeData.RouteHandler; (MvcRouteHandler implements IRouteHandler, which is part of the routing API.  MvcRouteHandler is just a very thin adapter between routing and Mvc.)
  • mvcHandler = mvcRouteHandler.GetHttpHandler();
  • mvcHandler.ProcessRequest(httpContext);  (MvcHandler implements IHttpHandler.)
    • Gets the controller name from the RouteData.
    • Gets the singleton instance of DefaultControllerFactory.
    • controller = factory.CreateController(requestContext, controllerName);
    • controller.Execute(requestContext);
      • Creates a ControllerContext, which is just the RequestContext plus a reference to the controller instance.
      • Gets the action name from the RouteData.
      • Creates an ActionInvoker
      • actionInvoker.InvokeAction(controllerContext, actionName)
        • Maps values in the RouteData to parameters on the action method with matching names
        • If there are complex parameter types that can’t be directly mapped from RouteData values, the invoker instantiates an IModelBinder for each parameter and calls BindModel() on it to get the parameter value.
        • Invokes the action method with all the parameters.
          • In typical usage, action methods get data, add that data to the ViewData dictionary and/or the Model property. Then the action method calls the controller’s View() method.
          • controller.View() method:
            • Gives each registered view engine an opportunity to “claim” the view. The default WebFormViewEngine uses the virtual path to locate the view. The default virtual paths it checks are:
              • ~/views/{controller}/{action}.aspx and .ascx
              • ~/views/shared/{action}.aspx and .ascx
            • View() returns a ViewResult object (derived from ActionResult) containing a reference to the view engine and the virtual path to the view.
          • The action method typically returns the ViewResult it gets from View().
        • The invoker calls result.ExecuteResult():
          • When called on a ViewResult, this method asks the view to render itself:
          • view.Render(outputWriter)
            • Performs the rendering and writes the output directly to the outputWriter (which is the HTTP response stream).

If you want to follow along, you’ll need to download ScottGu’s sample, which I’ll use as my starting point.  The sample (MvcApplication5) uses the MvcToolkit, but I found I had to download MvcToolkit and repair the reference to before I could successfully build and run the sample.

Creating the IProductsRepository interface

The first step is to create an IProductsRepository interface.  We’ll use VS2008′s refactoring support to extract an interface from Scott’s NorthwindDataContext partial class.  Open that file in the editor, right-click on the partial class declaration and choose Refactor > Extract Interface.

Name the interface IProductsRepository and select just the five methods that Scott added in the partial class.

That will create IProductsRepository.cs in the Models folder with the new interface.

It also adds the interface to the NorthwindDataContext declaration.  Now we can go to the ProductsController in the Controllers directory and change the northwind field to be of type IProductsRepository.

At this point, we have a problem.  Both the Create() and Update() action methods call SubmitChanges() on the data context.  When we try to build, the compiler tells us that the SubmitChanges method isn’t part of the IProductsRepository interface.  The whole goal here is to reduce the coupling between the controller and the Linq-generated DataContext.  So we’re going to move the Linq code into the partial class and access it through the interface we just created.

Let’s start with Create().  Create() calls AddProduct() on the data context, which looks like this:

Let’s add a call to SubmitChanges() to AddProduct():

We have to remove SubmitChanges() from Create():

There is no method in our IProductsRepository interface that the controller can call when updating a product, so we’ll create a SaveProduct() method in the interface and implement it in NorthwindDataContext.  The only thing our implementation of SaveProduct() will do is call SubmitChanges().  So Update() looks like this:

And SaveProduct() like this:

Setting up for dependency injection with Windsor

At this point, everything works as before, we’ve just added an interface and moved some calls to SubmitChanges().  ProductsController and NorthwindDataContext are still tightly coupled.  For the next part, we’re going to use dependency injection and our new interface to break the coupling.  For some background on dependency injection and why you might want to use it, see this article and links by James Shore.

There are a number of tools that will do dependency injection for you.  We’re going to use Windsor from the Castle Project.  We’ll also use MvcContrib, a community-driven project on CodePlex that is developing useful add-ons to ASP.NET MVC.  One of those add-ons is a WindsorController, which allows us to easily use dependency injection on our controllers.

You’ll also need to download the latest release of the MvcContrib project.  I’m using the beta version 0.0.1.32 in this sample.  We need to add a couple of references to the MvcToolkit assemblies.  When you download the binaries version, you’ll have a bin directory with the assemblies and a Samples directory with some code that we’ll use below.

Add references in MvcApplication5 to:

• Castle.Core.dll
• Castle.MicroKernel.dll
• Castle.Windsor.dll
• MvcContrib.dll
• MvcContrib.Castle.dll.

Now we need to modify our Global.asax.cs file so that our web application automatically creates a Windsor Container.  All of these changes are below are also shown in the sample app provided in the MvcContrib download.

• Add using statements for the Castle.Core and Castle.Windsor namespaces.
• Implement the IContainerAccessor interface, which has a single property named Container.
• Add a static field to hold the container, and a static property to wrap it.

Here’s what they look like so far:

Next up is to instantiate the container and make it aware of all the controller classes in our application.  This is done by looking for all types in the current assembly that can be cast to the IController interface.

• Add a using statement for the MvcContrib.ControllerFactories namespace.
• Copy in the InitializeWindsor() method from the sample app.
• Refactor the route handling setup from Application_Start() to a separate method named AddRoutes().
• Change the Application_Start() handler to call InitializeWindsor() and AddRoutes().

The end result in Global.asax.cs is:

Two changes to the sample code are required.  The first change is to tell the WindsorContainer to use the web.config file to get the configuration values.  We’ll go into the config settings in the next section.  Here all we need to do is pass into the WindsorContainer constructor a new XmlInterpreter().  This tells the container to use the current app.config or web.config file.

The sample uses a controller class named WindsorController to get access to the assembly containing all the controllers.  Since we don’t have a WindsorController type, our second change is to:

• Add a using statement for the MvcApplication5.Controllers namespace.
• In the InitializeWindsor() method (line 42 in the screenshot) change “typeof(WindsorController)” to “typeof(HomeController)”.  I use HomeController, since most ASP.NET MVC applications will have one of those.

After these changes, the two lines in InitializeWindsor() look like this:

Injecting the repository into ProductsController

Getting back to our ProductsController class, remember that we changed the northwind field to be of type IProductsRepository, but we still populated it with an instance of NorthwindDataContext. What we want is for ProductsController to know nothing about NorthwindDataContext.  Any class that implements IProductsRepository should work just fine for retrieving and saving products.

First, we’ll remove the assignment of the NorthwindDataContext instance.  While doing this, we’ll change the field name from “northwind” to “repository” to make it more generic.  VS2008′s refactoring support makes this a breeze.  Then we’ll add a constructor that takes a parameter of type IProductsRepository.  (Make sure the IProductsRepository interface is declared as public, since we didn’t do that earlier.)  The result is:

We’re now ready to tell Windsor: “Whenever you create a ProductsController, pass a NorthwindDataContext into its constructor.”  We do that through a config section in web.config.  First declare a section for castle in the <configSections> element and add a <castle> element as follows:

What we’re telling Windsor here is that whenever a controller has a constructor parameter of type IProductsRepository, give it a new instance of NorthwindDataContext.

At this point, we can run the application to see that it all works just like it did in Scott’s original version.  The difference now is that our controller and data context are no longer tightly coupled.  If we wanted to change from Linq to some other ORM tool, or to move the Products table to a different Linq data context class than the rest of Northwind, before we’d have to make a bunch of code changes.  Now all we have to do is update our web.config file to point Windsor at a class that implements IProductsRepository and we’re done.

Enjoy.  And please comment on what’s confusing, what I glossed over too quickly, and what I spent too much time explaining.  I’m still getting the hang of this and welcome any suggestions.

When ASP.NET and WebForms came along, I was always doing “View source” to see exactly what those magical server controls were doing.  Once I understood how it worked, I began to trust it.  Over time, I spent less and less time worrying about the exact HTML that was rendered.  The productivity benefits of WebForms and server controls were the main focus.  I learned to trust the automagic-ness.  You can create some amazing things very quickly.

There are certainly drawbacks to WebForms:  only one server form (with runat=”server”) per page, out-of-control viewstate if you weren’t careful, postbacks always going to the same page, etc.  But over time, the community developed techniques to mitigate those drawbacks and make them workable.  I still believe the WebForms model is a very good thing.

As web development has become a major part of the development effort in most organzations, the roles have become more specialized.  Unlike the old days, a single person is not typically creating images in Photoshop, writing HTML (and now CSS), writing JavaScript, writing WebForms and writing business and data access classes.  In my company, we have designers who create page mock ups in Photoshop; interface developers who turn those into HTML, CSS and JavaScript; and server-side developers who write server-side code.  (Let’s leave aside the issue of whether that’s the “right” way to organize a team.  The fact is that many companies, including mine, do it that way.)

There is an impedence mismatch between these roles and the way WebForms work.  Say your interface engineer turns the Photoshop page comps into a bunch of HTML files.  Your server-side developers — looking at those HTML files in the context of the entire site — break them up into master pages, pages, and controls in some logical way that optimizes the development of the server-side code.  Then the inevitable changes come.  Do you have the interface developers rewrite the HTML, and the server-side developers try to figure out how to apply the changes in the server-side structure?  Or do you have the interface developers start working in your .ascx and .aspx files directly?  If they don’t have Visual Studio or a full dev environment set up, how can they effectively do the edit-refresh cycle to do their work?  The same types of issues crop up when you talk about a global.js JavaScript file vs. RegisterClientScript(), and with CSS files vs. ASP.NET themes.

Those challenges help explain why I’m so excited about the new ASP.NET MVC framework.  Everything I’ve seen so far looks like a combination of the power and productivity of WebForms, the total control of the rendered HTML of classic ASP, and a very nice alignment with the division of labor found in many web development shops.

I’m writing this post in Graffiti beta 1, which also uses an MVC model and NVelocity as the view engine.  The views are really clean and simple, and it’s simple to write powerful server-side helpers to produce modern CSS-styled HTML.  I can’t wait to have that structure baked into ASP.NET.

• 1.0.61112.123
  • Production
  • QA
  • Staging

With the non-updatable option selected in the web deployment project, all the .ascx and .master files are removed during compilation. They’re compiled, so we don’t need them anymore, right? Right. Well, when we copy files to the output directory, our /MasterPages and /UserControls directories don’t have any files, so those directories don’t get recreated in the output. Unfortunately, it looks like we need those empty directories. When we run the site, ASP.NET seems unable to find either the master pages or any user controls if the directories they were originally in don’t exist.

Our workaround is to create an empty “dummy.config” file in each directory that we need to have show up in the running site. Config files are harmless, and ASP.NET won’t let them be retrieved through a browser. Alternatively, we could add a step to our build file that deletes all the dummy.config’s after copying to the output.

My question is: Why does ASP.NET need the empty directories in order to locate the compiled .master and .ascx classes? Or are we just doing something wrong in the deployment project or in our overall build process?