Even though ScottGu and others have written about ASP.NET MVC I figured I’d add a series of notations about URL Routing, Controllers and Controller Actions, Rendering Helpers and Understanding the Model.

Who knows maybe the way I explain it will drive the point home.

Part 1 is just my overview of the ASP.NET MVC Framework

ASP.NET MVC Framework (Part 2): Understanding URL Routing

Background

WebForms

In ASP.NET Forms we used Server controls that must appear between a <form> tag. Each server control had to use a runat=”server” attribute to tell the server to process that form on the server.

ViewState

In classic ASP when forms were submitted all form values were cleared. Unfortunately if the form had an error then you lost all that information you submitted. In ASP.NET the form is able to return with all the form values.  ViewState is a way for the server to know the status of the page.

                Event Driven Programming

ASP.NET objects (server controls) on the webpage exposed events that allowed a programmer to process ASP.NET code. By having a Load, Click or Change event handled by code made coding much simpler and much better organized.

                ASP.NET 2.0

In ASP.NET 2.0 we received Master Pages, Themes and Web Parts, more server controls for navigation or security. The provider patterns for Roles, personalization or memberships, etc .

MVC Execution Process

With ASP.NET MVC Framework a web request now passes to an UrlRoutingModule object (HTTP module) which is then parses and a route is selected. Then an MvcHandler take the object and selects a controller instance that will call that controllers Execute method.

 So instead of Event Handlers we now have Controller Classes and instead of ViewState exposing certain sequences of events for programming, we now have full control over the behavior of an application.

Default Naming Conventions

 Pretty simple, if you have a controller name it UrlPathController  this is so the UrlRoutingModule and MvcHandler can determine which controllers to invoke. Any controller class has to implement the System.Web.MVC.IController. By implementing this IController you will gain access to using the [ControllerAction] Attribute, which we’ll get into next writing.

Mapping URLs to the Controllers

        MVC Framework has a default URL convention it follows to map URL’s. The syntax is:

                     URL = [Controller] / [Action] / [id]

http://domain/site/controller-name/action-method-name/parameters

   NOTE: If you see a controller-name.mvc this is required for anybody running IIS 6.0 as their web server

Global.asax

This file is used to define route mappings. You do this in the Application_Start event. The syntax is:

      // Note: Change Url= to Url="[controller].mvc/[action]/[id]"

      // to enable automatic support on IIS 6.0.

      RouteTable.Routes.Add(new Route

      {

        Url = "[controller]/[action]/[id]",

        Defaults = new { action = "Index", id = (string)null },

        RouteHandler = typeof(MvcRouteHandler)

      });

      RouteTable.Routes.Add(new Route

          {

            Url = "Default.aspx",

            Defaults = new { controller = "Home", action = "Index",

                id = (string)null },

            RouteHandler = typeof(MvcRouteHandler)

          });

This is saying Add a route to the RouteTable which lists my controller and action. Notice you are not required to give it a parameter or id initially.

Here are some example URLs to drive the point home:

Next blog we’ll get into the Controllers and Controllers Actions.

"MVC" It's practically a holy word in the world of software development.

What is Model View Controller (MVC)?

Some history: In software development we always strive to separate our behaviors in code. We normally do this in separate layers: Presentation (UI), Domain Logic or Business Logic Layer (BLL), and Data Access. This type of format was once called the 3-Tiered Architecture and has since been coined into a "n-tiered Architecture". Mainly because many software developers added other layers in-between the three core separations. By separating these layers we achieved low coupling and high cohesion between the code.

What does that mean?  It means that as clients changed their minds or as new technology emerged, we had to be flexibleand adapt to the new world. So we design our software to enable us to change any one of these layers with minimal effort. For Example, if our client decided to switch from a ASP.NET User Interface (UI) to an Adobe Flex then the change wouldn't have to be the entire codebase. Just the presentation layer.

In MVC the presentation layer is further separated into a View and Controller.

• "Model" represents enterprise data and business rules that govern access to and updates of this data. The model servers as software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. (e.g., calculating whether today is a users birthday, or a Scores class that is used to represent student scores from the Class Assignment table inside SQL)
• "View" renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achived by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
• "Controller" translates interactions with the view into actions to be performed by the model. So the controller will define the application behavior and map user actions to model updates. It can select views for response.
  

In Java they use JavaServerPages (JSP) to render the view, Servlet as the controller and Enterprise JavaBeans (EJB) components as the model.

As Wikipedia puts it best: Though MVC comes in different flavors, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g., presses a button).
2. A controller handles the input event from the user interface often via a registered handler or callback.
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g., controller updates user's shopping cart)
4. A view uses the model (indirectly) to generate an appropriate user interface (e.g., the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view.
5. The user interface waits for further user interactions, which begins the cycle anew.

What about the ASP.NET MVC Framework?

• Microsoft knows how to integrate their products so they play nice with each other. (When they plan this. cough..cough Sharepoint and TFS, One portal site.) So the ASP.NET MVC Framework fully supports the existing ASP.NET features.
  

• The MVC Framework does not use the post-back model for interaction's back to the server. You have to route all your user interactions to a controller class. This also means you no longer have viewstate or the page lifecycle on any of these MVC based views). But you can still use ASP.NET features such as server controls or master pages etc.
  

• URL Mapping component that lets you build your URLs. So you are able to map your URLs to actions of your controller class. That class could have that same URL be mapped to a "Edit" or a "View" action.
  

• ASP.NET MVC is built to help you separate your layers, deal with Red/Green Testing. You deal with the interfaces as I think it should be. MVC Framework even has a interface based IHttpRequest/IHttpResponse.
  

• MVC Framework Testing can be combined with pretty much every major known Unit Testing Framework out there (NUnit, MBUnit, MS Test, etc) You can also use the existing dependency injection and IOC container models (Windsor, Spring.Net, NHibernate, etc)

So if you are thinking about MVC. Think about ASP.NET Framework.

Resources
For some tutorials about how to use this take a look and learn from the experts.

ScottGu:

1. ASP.NET MVC Framework (Part 1)
2. ASP.NET MVC Framework (Part 2): URL Routing
3. ASP.NET MVC Framework (Part 3): Passing ViewData from Controllers to Views
4. ASP.NET MVC Framework (Part 4): Handling Form Edit and Post Scenarios

Fredrik Normen:

1. ASP.Net MVC Framework and data binding
2. ASP.Net MVC Framework - List and Save data
3. ASP.Net MVC Framework - Create your own IControllerFactory and use Spring.Net for DI
4. ASP.Net MVC Framework - Create your own IRouteHandler
5. ASP.Net MVC Framework - Creating a IRouteHandler which will support Interceptors
6. ASP.Net MVC Framework - Exception Handling
7. ASP.Net MVC Framework - Handling Exception by using an Attribute
8. ASP.Net MVC Framework - Security
9. ASP.NET MVC Framework - Ajax
10. MVC - Expression Language and custom tags