A Quick Look at the Basics of ASP.NET MVC

Saturday, November 10, 2007

I had a look at the demo code that Scott Hanselman made available :) So how does it look when using the ASP.NET MVC framework? Of course, since this is MVC, you got the "model", "view" and "controller" parts, but when listening to Scott Guthrie, it seems to be more about "router", "view" and "controller" and he's repeating the fact that this framework is very extensible - you can go with the out of the box stuff, or hack up your own.

The aim seems to be to have a very clean separation of these parts, so you can swap out the view enging if you want to, and it should also be easier to test your application for those of you who are into TDD and unit testing in general. Therefore there is also support for dependency injection.

The old ASP.NET stuff that we know and love is still there - code behind, controls, authentication and roles and such. The default view engine is ASPX, but postbacks are not supported, so obviously the way you use some of the ASP.NET controls will change.

One big difference with URLs in standard ASP.NET vs. MVC is that they do not point directly at the page (like default.aspx) to be rendered, but at a "Controller" which handles the business logic, processes the data and then renders it to a view (which could be the default.aspx page for example). The trick is to map the URL to a controller, and this part seems to be very "configurable". The REST-style of URLs is used alot in the demos, so for example:

    /products/
    /products/42
    /products/delete/42

Thanks to a URL routing engine, the right method, in a specific controller will be targeted for each URL above, with the right parameters supplied, like:

/<controller>/<action>/<parameter>

So, stealing a sample from Guthrie's demo, to set up a Route for URLs like these:

   /Home
   /Home/Index
   /Home/PrintNumber/45

you would do something like this:

Routes.Add(new Route("Home", "/Home/[action]/[id]", typeof(HomeController)));

For the route above, which could be initiated in Global.asax, all URLs that begin with "/Home" will be handled by HomeController which will have methods to handle the "Index" and "PrintNumber" actions. There are several ways to set up default controllers and actions, but I'm now going into that here.

Note: this was how it was demoed in the ALT.Net video by Guthrie, but it seems that have changed in released demo code. I'll look closer at it later.

The HomeController class could look something like this:

public class HomeController : Controller
{
    [ControllerAction]
    Index()
    {
      //add code here for the default "view"...
    }

    [ControllerAction]
    PrintNumber(int number)
    {
      //add code here to print out a number...
    }
}

The [ControllerAction] attribute was added for security reasons so that anyone just cannot type in any action in the URL and run methods in the controller that wasn't supposed to be run. If you don't like that attribute, it's a policy that can be overridden.

To make the Controller Action output something to the browser, you could use the Response object like this:

[ControllerAction]
Index()
{
Response.Write("<b>You're at the Index Page (action)!</b>");
}

or you could (will in most cases) point at a view (like an ASPX page) to handle the rendering like this:

RenderView("Home");

which would render a "Home.aspx" view page you've created.

If you want to pass parameters to the view, you could use the ViewData collection and do:

    [ControllerAction]
    PrintNumber(int number)
    {
      ViewData("number") = number;
      RenderView("ShowNumber");
    }

and the page "ShowNumber.aspx" would have some HTML in it to handle the printing of that number, like so:

<body>
      <div>
          The number waws: <%= ViewData["number"] %>
      </div>
</body>

There are ways to pass data to the view in a strongly typed way, by letting the Controller class inherit from a Controller<T> where T is a simple class used to hold properties you'd like to pass to the view. Then ViewData would be of type T. Normally, the code behind for the ASPX page used for the view inherits from the class ViewPage (which is a difference from ordinary ASP.NET pages), but when using Controller<T>, the ASPX-page should inherit from ViewPage<T> to get strong typing of the ViewData class too. Nice!

I guess that's enough to just let you get a glimpse of how this stuff will work. I'm sure things will change over time, but I believe this is the general idea.

1 Comment