CodeStock 2008 ASP.NET MVC

By CSharpner · August 13, 2008

August 9th, 2008 was the 1st annual CodeStock convention. For a rundown of the events, click here. Telerik's main evangelist, Todd Anglin gave a great presentation on Microsoft's still beta ASP.NET MVC product. If you've never heard of it, first, let me explain what MVC is:

MVC is an acronym for Model, View, Controller. It is a design pattern, not a product. But, Microsoft has created a product based on this design pattern. The design pattern stresses separation of concerns, meaning, your code and your user interface are completely decoupled and unaware of each other. In other words, your user interface layer has zero code that talks to your "model" (or business logic) and your business logic (model) has no code that interacts with the user interface. This provides many advantage, including, but not limited to:

  • True reusability of your business logic. Can be used in multiple projects with no modification.
  • TDD - Automatically makes your business logic (your model) testable by common test utilities like NUnit.

Now, to define the three words in the acronym:
  • Model - This is your business layer. It is code only. You can easily make this as a DLL or a class library all by itself.
  • View - This is your presentation or your HTML.
  • Controller - This is the plumbing that sits between your Model and your View. This is really where most of Microsoft's new ASP.NET MVC framework comes into play.

That's MVC in a nutshell. Now, for Microsoft's implementation of it: Normally, a design pattern is not a product, but a concept or practice, but Microsoft has provided a new framework (several DLLs with new classes and some Visual Studio project templates... packaged as a single download) specifically to support this design pattern. It should be pointed out and made very clear that ASP.NET MVC is an alternative to WebForms. This means that you use either ASP.NET MVC or WebForms. If you use ASP.NET MVC, you will throw out EVERYTHING you've learned about writing web apps with .NET WebForms. ASP.NET MVC does not have visual controls that you can drag and drop onto a form. It does not have events on those controls (because there are no controls).

If you think that without the visual controls, you'd be writing a heck of a lot more HTML, you're right, unfortunately. As a side note, Telerik has begun work on this. They will be creating a control set for ASP.NET MVC. I believe as of this writing (2008-08-13), they are still in the "how are we going to do this" stage, which means you have an opportunity to give them suggestions. I would encourage you to go to www.telerik.com and provide some feedback for them.

Back to writing more HTML: This, is of course, a VERY BAD thing. I hate having to get down and dirty with HTML and I do it as little as possible. I like to drag, drop, select an event and write my handler. I come from a non-web programming background and don't much care for having to tinker with HTML... but enough about my personal opinions... Since your view (UI) and your model (business logic) are completely separated, your view is simply nothing more than just plain old presentation, which means HTML. The way you connect your UI clicks and such to your code is via URLs. Nothing has an .aspx extension. You have complete control over your URLs. You don't have pages, per se, like you do with .aspx pages. All of your UI actions are directed to a URL and your URLs don't necessarily have any real correlation to folders in your project.

You controller code is what links your URLs to classes and methods in your model. I won't get into code samples here, but that's the gist of it.

Now, on to my session notes from Todd's presentation at CodeStock 2008. These notes were taken while he was speaking and are in outline form. They are for my personal use, but I'm including them here in case they may be of use to you:

  • Separation of concerns.
  • Alternative, not a replacement for ASP.NET web forms.
  • More control over HTML and URLs
  • Easier Testing
  • No unexpected rendering
    • HTML is 100% by you (nothing rendered by the framework).
      • No automatic fluff like ViewState (There is NO VIEWSTATE!!! (good or bad))
  • No file extensions (no .aspx)
    • URL -> Controller -> Model -> View Data (ie. display.aspx, edit.aspx)
    • Request -> HTTP Routing -> Route -> Route Handler -> ...
  • Map URLs to class.
  • Classes handle processing of actions (decide which view to render).
  • Everything is interface based (as opposed to class).
  • Everything is extensible - read up on C# extension methods
  • Everything is testable
  • Microsoft.Web.Mvc.dll
  • Define your routes in global.asax.
  • Define controller, views
    • User HTML Helpers to render HTML (html helpers are new classes in the ASP.NET MVC framework). Don't waste time manually writing C# code that generates HTML... use the helper classes.
  • Define Model (Lina to Sql, for example)
  • Key differences from webforms (didn't write any down)
  • You Must target .NET Framework v3.5.
  • Will eventually support NUnit.
    • When you make a new ASP.NET MVC project in Visual Studio, it will prompt you, immediately, for the test framework you want to use to make your test classes. THIS IS VERY VERY IMPORTANT! YOU SHOULD DEFINITELY DO THIS!!!!
  • You maintain state... There are no session variables or view state or application variables or server variables... you do this on your own. (great! Now every code monkey is going to have their own, custom, proprietary, and buggy state management system!!!)
  • View
    • Can be anything, not just HTML... you could generate SQL or C# or XML or some binary stream... anything.
    • Controller creates (key, value) dictionary "ViewData" and gives to view. View uses it to render output.
  • HTML Helper
    • is a shortcut to rendering html.
    • HTML.ActionLink
  • Controller folder has a file per controller (the ASP.NET MVC project template creates several folders in your project... Controller is one of them).
  • Views folder has a view for each controller.
  • Routes are matched by order defined... In other words, if you've defined multiple routes that can all handle a single URL, the first one defined is the one that gets it.
  • You should make mock classes to help with your unit testing. Some mock tools are:
    • RhinoMocks
    • Moq
    • TypeMocks

________________________
notes to myself:
Those were my quick and dirty notes. I took them for myself, but I posted them anyway, because they could potentially have some use to others.
If you're interested in attending CodeStock 2009, contact http://codestock.org/.