In this walkthrough, you will create and run the sample MVC application. Then you will customize the application by adding a controller and a view.

Prerequisites

In order to complete this walkthrough, you will need:

• Microsoft Visual Studio 2008 Service Pack 1.
• ASP.NET MVC 1.0.

You can download and install the ASP.NET MVC framework in the following ways:

• Install the framework using the Microsoft Web Platform Installer. You can download the installer from the installation page on the Microsoft Web gallery site.
• Download the framework from the ASP.NET MVC 1.0 page on the Microsoft Download Center.

Creating a New MVC Project

1. On the File menu, click New Project.
   The New Project dialog box is displayed.
   
2. In the upper-right corner, make sure that .NET Framework 3.5 is selected.
3. Under Project types, expand Visual Basic and then click Web.
4. Under Visual Studio installed templates, select ASP.NET MVC Web Application.
5. In the Name box, enter MvcBasicWalkthrough.
6. In the Location box, enter a name for the project folder.
7. If you want the name of the solution to differ from the project name, enter a name in the Solution Name box.
8. Select Create directory for solution.
9. Click OK.
   The Create Unit Test Project dialog box is displayed.
   
10. Select No, do not create a unit test project.
11. Click OK.
    The new MVC application project and a test project are generated.

Examining the MVC Project

The following illustration shows the folder structure of a newly created MVC solution. 

The folder structure of an MVC project differs from that of an ASP.NET Web site project. The MVC project contains the following folders:

• Content, which is for content support files. This folder contains the cascading style sheet (.css file) for the application.

• Controllers, which is for controller files. This folder contains the application’s sample controllers, which are named AccountController and HomeController. The AccountController class contains login logic for the application. The HomeController class contains logic that is called by default when the application starts.

• Models, which is for data-model files such as LINQ-to-SQL .dbml files or data-entity files.

• Scripts, which is for script files, such as those that support ASP.NET AJAX and jQuery.

• Views, which is for view page files. This folder contains three subfolders: Account, Home, and Shared. The Account folder contains views that are used as UI for logging in and changing passwords. The Home folder contains an Index view (the default starting page for the application) and an About page view. The Shared folder contains the master-page view for the application.

The newly generated MVC project is a complete application that you can compile and run without change. The following illustration shows what the application looks like when it runs in a browser.The unit-test project is also ready to compile and run. For this walkthrough, you will add a controller with an action method and a view.

Adding a Controller

You will now add a controller that contains logic for downloading city maps from the Microsoft Virtual Earth Web service.

1. In Solution Explorer, right-click the Controllers folder, click Add, and then click Controller.
   The Add Controller dialog box is displayed.
2. In the Name box, type MapsController.
   The ASP.NET MVC framework requires controller names to end with "Controller", such as HomeController, GameController, or MapsController.
3. Clear the Add action methods for Create, Update, and Details scenarios check box.
4. Click Add.
   Visual Studio adds the MapsController class to the project and opens it in the editor.

Adding Code to the Action Method

You will now add code to the MapsController class for the ViewMaps action method in order to render the Maps view.

1. Open the MapsController class and replace the ViewMaps action-method stub with the following code in order to render the Maps view.

   Function ViewMaps() As ActionResult
       Return View()
   End Function

2. Save and close the file.

Adding a View

Next, you will add a Maps view. To keep the views organized, you will first add a Maps folder under the Views folder.

1. Open the MapsController class, right-click inside the ViewMaps action method, and then click Add View.

   The Add View dialog box is displayed.

   

2. In the View name box, enter ViewMaps.aspx.
3. Clear the Create a partial view (.ascx) check box and the Create a strongly-typed view check box.
4. Select the Select master page check box and set the master page to ~/Views/Shared/Site.Master.
5. Set ContentPlaceHolder ID to "MainContent".
6. Click Add.

   The new view is added to the project in the Maps folder

Adding Content to the View

Next, you will add content to the new view.

1. Open ViewMaps.aspx and add the following content inside the Content element:

   <h2>My City Maps</h2>
   Select map:
   <select onclick="GetMap(value);">
       <option value="Seattle">Seattle, WA</option>
       <option value="LasVegas">Las Vegas, NV</option>
       <option value="SaltLake">Salt Lake City, UT</option>
       <option value="Dallas">Dallas, TX</option>
       <option value="Chicago">Chicago, IL</option>
       <option value="NewYork">New York, NY</option>
       <option value="Rio">Rio de Janeiro, Brazil</option>
       <option value="Paris">Paris, France</option>
       <option value="Naples">Naples, Italy</option>
       <option value="Keta">Keta, Ghana</option>
       <option value="Beijing">Beijing, China</option>
       <option value="Sydney">Sydney, Australia</option>
   </select>
   <br />
   <br />
   <div id='earthMap' style="position:relative; width:400px; height:400px;">
   </div>
   <script charset="UTF-8" type="text/javascript"
       src="http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2&mkt=en-us">
   </script>
   <script type="text/javascript">
       var map = null;
       var mapID = '';
   
       function GetMap(mapID)
       {
           switch (mapID)
           {
               case 'Seattle':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(47.6, -122.33), 10 ,'i', true);
                   break;
               case 'LasVegas':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(36.17, -115.14), 10 ,'i' ,true);
                   break;
               case 'SaltLake':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(40.75, -111.89), 10 ,'i' ,true);
                   break;
               case 'Dallas':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(32.78, -96.8), 10 ,'i' ,true);
                   break;
               case 'Chicago':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(41.88, -87.62), 10 ,'i' ,true);
                   break;
               case 'NewYork':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(40.7, -74), 10 ,'i' ,true);
                   break;
               case 'Rio':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(-22.91, -43.18), 10 ,'i' ,true);
                   break;
               case 'Paris':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(48.87, 2.33), 10 ,'i' ,true);
                   break;
               case 'Naples':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(40.83, 14.25), 10 ,'i' ,true);
                   break;
               case 'Keta':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(5.92, 0.983), 10 ,'i' ,true);
                   break;
               case 'Beijing':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(39.91, 116.39), 10 ,'i' ,true);
                   break;
               case 'Sydney':
                   map = new VEMap('earthMap');
                   map.LoadMap(new VELatLong(-33.86, 151.21), 10 ,'i' ,true);
            }
       }
   </script>

   This markup defines a drop-down list for selecting a map and the JavaScript logic for retrieving the selected map from the Microsoft Virtual Earth Web service.

2. Save and close the file.

Adding a Tab to the Master-Page Menu

You will now add an item to the master-page menu that calls the ViewMaps action method.

1. In the Shared folder, open the Site.master file and locate the unordered list (ul element) in the div element whose ID is "menucontainer".
2. Add the following code to the list between the Index and About Us tabs:

   <li><%= Html.ActionLink("My City Maps", "ViewMaps", "Maps")%></li>

   The ActionLink method is a helper method that links to an action method. It takes the following parameters: the text for the link, the name of the action method, and the name of the controller.

3. Save and close the file.

Testing the MVC Application

You can now test the application.

1. In Solution Explorer, select the walkthrough project and press CTRL+F5 to run the application.

   The Index.aspx page is displayed, which includes the tabs that are defined in the master page.

2. Click the My City Maps tab.

   The My City Maps page is displayed. Select any map to see it displayed.

   

Next Steps

This walkthrough gives you a first look at creating an MVC application and working with unit tests in ASP.NET MVC. From here, you might want to learn more about the ASP.NET MVC framework. The following list suggests topics for additional learning.

• For more information about MVC controllers
  
     see Controllers and Action Methods in MVC Applications.

• For more information about MVC views
  
     see Views and UI Rendering in MVC Applications.

• For more information about MVC models
  
     see Models and Model Binders in MVC Applications.

Context

The purpose of many computer systems is to retrieve data from a data store and display it for the user. After the user changes the data, the system stores the updates in the data store. Because the key flow of information is between the data store and the user interface, you might be inclined to tie these two pieces together to reduce the amount of coding and to improve application performance. However, this seemingly natural approach has some significant problems. One problem is that the user interface tends to change much more frequently than the data storage system. Another problem with coupling the data and user interface pieces is that business applications tend to incorporate business logic that goes far beyond data transmission.

Problem

How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts?

Forces

The following forces act on a system within this context and must be reconciled as you consider a solution to the problem:

• User interface logic tends to change more frequently than business logic, especially in Web-based applications. For example, new user interface pages may be added, or existing page layouts may be shuffled around. After all, one of the advantages of a Web-based thin-client application is the fact that you can change the user interface at any time without having to redistribute the application. If presentation code and business logic are combined in a single object, you have to modify an object containing business logic every time you change the user interface. This is likely to introduce errors and require the retesting of all business logic after every minimal user interface change.
• In some cases, the application displays the same data in different ways. For example, when an analyst prefers a spreadsheet view of data whereas management prefers a pie chart of the same data. In some rich-client user interfaces, multiple views of the same data are shown at the same time. If the user changes data in one view, the system must update all other views of the data automatically.
• Designing visually appealing and efficient HTML pages generally requires a different skill set than does developing complex business logic. Rarely does a person have both skill sets. Therefore, it is desirable to separate the development effort of these two parts.
• User interface activity generally consists of two parts: presentation and update. The presentation part retrieves data from a data source and formats the data for display. When the user performs an action based on the data, the update part passes control back to the business logic to update the data.
• In Web applications, a single page request combines the processing of the action associated with the link that the user selected with the rendering of the target page. In many cases, the target page may not be directly related to the action. For example, imagine a simple Web application that shows a list of items. The user returns to the main list page after either adding an item to the list or deleting an item from the list. Therefore, the application must render the same page (the list) after executing two quite different commands (adding or deleting)-all within the same HTTP request.
• User interface code tends to be more device-dependent than business logic. If you want to migrate the application from a browser-based application to support personal digital assistants (PDAs) or Web-enabled cell phones, you must replace much of the user interface code, whereas the business logic may be unaffected. A clean separation of these two parts accelerates the migration and minimizes the risk of introducing errors into the business logic.

Solution

The Model-View-Controller (MVC) pattern separates the modelling of the domain, the presentation, and the actions based on user input into three separate classes [Burbeck92]:

• Model. The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
• View. The view manages the display of information.
• Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Figure 1 depicts the structural relationship between the three objects.

Figure 1: MVC class structure

It is important to note that both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation. The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In Web applications, on the other hand, the separation between view (the browser) and controller (the server-side components handling the HTTP request) is very well defined.

Model-View-Controller is a fundamental design pattern for the separation of user interface logic from business logic. Unfortunately, the popularity of the pattern has resulted in a number of faulty descriptions. In particular, the term “controller” has been used to mean different things in different contexts. Fortunately, the advent of Web applications has helped resolve some of the ambiguity because the separation between the view and the controller is so apparent.

Variations

In Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC) [Burbeck92], Steve Burbeck describes two variations of MVC: a passive model and an active model.

The passive model is employed when one controller manipulates the model exclusively. The controller modifies the model and then informs the view that the model has changed and should be refreshed (see Figure 2). The model in this scenario is completely independent of the view and the controller, which means that there is no means for the model to report changes in its state. The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server. The browser displays the view and responds to user input, but it does not detect changes in the data on the server. Only when the user explicitly requests a refresh is the server interrogated for changes.

Figure 2: Behaviour of the passive model

The active model is used when the model changes state without the controller’s involvement. This can happen when other sources are changing the data and the changes must be reflected in the views. Consider a stock-ticker display. You receive stock data from an external source and want to update the views (for example, a ticker band and an alert window) when the stock data changes. Because only the model detects changes to its internal state when they occur, the model must notify the views to refresh the display.

However, one of the motivations of using the MVC pattern is to make the model independent from of the views. If the model had to notify the views of changes, you would reintroduce the dependency you were looking to avoid. Fortunately, the Observer pattern [Gamma95] provides a mechanism to alert other objects of state changes without introducing dependencies on them. The individual views implement the Observer interface and register with the model. The model tracks the list of all observers that subscribe to changes. When a model changes, the model iterates through all registered observers and notifies them of the change. This approach is often called “publish-subscribe.” The model never requires specific information about any views. In fact, in scenarios where the controller needs to be informed of model changes (for example, to enable or disable menu options), all the controller has to do is implement the Observer interface and subscribe to the model changes. In situations where there are many views, it makes sense to define multiple subjects, each of which describes a specific type of model change. Each view can then subscribe only to types of changes that are relevant to the view.

Figure 3 shows the structure of the active MVC using Observer and how the observer isolates the model from referencing views directly.

Figure 3: Using Observer to decouple the model from the view in the active model

Figure 4 illustrates how the Observer notifies the views when the model changes. Unfortunately, there is no good way to demonstrate the separation of model and view in a Unified Modelling Language (UML) sequence diagram, because the diagram represents instances of objects rather than classes and interfaces.

Figure 4: Behaviour of the active model

Resulting Context

Architecting the presentation layer around the MVC pattern results in the following benefits and liabilities:

Benefits

• Supports multiple views. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects. Another example is a Web application that allows the user to change the appearance of the pages. These pages display the same data from the shared model, but show it in a different way.
• Accommodates change. User interface requirements tend to change more rapidly than business rules. Users may prefer different colours, fonts, screen layouts, and levels of support for new devices such as cell phones or PDAs. Because the model does not depend on the views, adding new types of views to the system generally does not affect the model. As a result, the scope of change is confined to the view.

Liabilities

• Complexity. The MVC pattern introduces new levels of indirection and therefore increases the complexity of the solution slightly. It also increases the event-driven nature of the user-interface code, which can become more difficult to debug.
• Cost of frequent updates. Decoupling the model from the view does not mean that developers of the model can ignore the nature of the views. For example, if the model undergoes frequent changes, it could flood the views with update requests. Some views, such as graphical displays, may take some time to render. As a result, the view may fall behind update requests. Therefore, it is important to keep the view in mind when coding the model. For example, the model could batch multiple updates into a single notification to the view.

Example

Part two of this post will describe implementing the MVC model in ASP.NET.

Acknowledgements:
Model-View-Controller began as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s [Fowler03]. The version you have just read references the following works:
[Burbeck92] Burbeck, Steve. “Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC).“University of Illinois in Urbana-Champaign (UIUC) Smalltalk Archive.
[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
[Gamma95] Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.