Microsoft ASP.NET 4 : The ASP.NET MVC Framework - The Model-View-Controller (MVC) Architecture

8/9/2012 4:10:35 PM
As many aspects of ASP.NET have stabilized and matured over the years, some interesting new features have appeared. Of the new features, ASP.NET application of the classic Model-View-Controller (MVC) software development pattern has probably received the most attention of all.

The ASP.NET MVC framework represents an alternative to the ASP.NET Web Forms environment. Web Forms offers a structured, controls-based framework for generating Web pages. Using Web Forms can make it feel like you're developing a desktop or rich client application even though the application UI is built upon HTML transmitted over a disconnected protocol. The basis of a Web Forms page is a collection of server-side controls—each one dedicated to emitting some HTML toward the output stream that eventually ends up at the client. Web Forms offers developers great leverage through its ability to handle view state and its event model. The Microsoft Visual Studio Designer has extensive support for Web Forms. You can develop entire pages and not have to deal with much, if any, raw HTML.

By contrast, the MVC framework works "closer to the metal." That is, as a developer, you're on the hook to work with some raw HTML. However, rather than leaving you in the wild to concoct a framework to manage the main application concerns (data and the UI), the MVC framework incorporates an industry-recognized software pattern for coordinating the two concerns. The MVC model draws strict distinctions between an application's data, its rendering, and its request processing. Each of these concerns is handled by a separate software component, and together they operate in concert with each other to handle HTTP requests.

1. The Model-View-Controller (MVC) Architecture

Modern software is complex. As you've seen so far, even developing Web applications using a framework that hides as much detail as ASP.NET does can become fairly involved. Many times, the complexity comes down to a problem of managing multiple concerns. For example, a typical ASP.NET application involves dealing with a data source (often a database), making sure the HTML rendered by the application is in sync with the application state, and managing the incoming and outgoing message traffic.

By itself, ASP.NET has separate components for managing these concerns. ADO, LINQ, and the entity framework work well for talking to a database. ASP.NET data binding and the data-bound controls help to keep the client view of the data current. Together with the ASP.NET pipeline, the ASP.NET control architecture hides the details of managing incoming and outgoing message traffic. Although these features of ASP.NET make Web development very approachable, there are other approaches to Web development. MVC offers an alternative means for handling HTTP requests.

The MVC pattern is tailor-made for Web applications. MVC divides the three main concerns of a typical Web application (managing data, keeping the visual aspect of an application in sync with its internal state, managing message traffic) and handles each through three separate components: a model, a view, and a controller. The model handles data access and management and application state, the view handles the visual representation of the application state, and the controller manages message traffic.

The MVC model component is responsible for maintaining application state, as well as sometimes hosting code not tied directly to the view. Application state is often managed through a persistent database. In an MVC-based application, the model encapsulates low-level database access. For example, the model for a human resources application might include an Employee class that represents rows from a table of employee information in a human resources database. It might also include a collection of Employee classes in an in-memory structure.

MVC view components render the application's user interface. This might include some controls (for example, to display and edit data). These controls are usually tied to the model data. For instance, an application might display separate views for showing employee data and for editing employee data. The details view might simply render the details in read-only form, while the editing view might include controls for editing the employee information fields.

Finally, MVC controller components manage interactions with the end user. Although the view component is responsible for rendering, rendering remains distinct from user interaction. Within the context of ASP.NET, managing user interaction means managing Web traffic, updating the model (the application state), and ultimately managing the UI (that is, emitting the correct HTML).

Figure 1 illustrates the relationships between all three components. Notice that the controller talks to the model and the view. That is, the controller updates the model as necessary, and it also interacts with the view when rendering. The view talks with the model to make sure it's displaying the most current application state.

Figure 1. The relationship between the model, the view, and the controller.

2. ASP.NET and MVC

MVC came to ASP.NET fairly recently. You can think of ASP.NET as a very loosely coupled set of classes working together to handle requests. ASP.NET includes a pipeline that acts as a substrate with different kinds of handlers hooked on to it. The pipeline is configured so that requests for various file types go to their correct handlers.

As useful as ASP.NET is for handling Web requests, ASP.NET is not quite a true framework. ASP.NET Web Forms mingles the concerns of the Web developer. MVC distinguishes itself as a framework by drawing a clear separation between the concerns of Web developers. Remember, models handle application state, views handle rendering, and controllers handle interactions with the end user.

The ASP.NET MVC framework coexists with the other parts of ASP.NET. The framework operates independently of the standard .aspx and .ascx files, master pages, and Global.asax files. MVC also works with the ASP.NET Forms Authentication and the standard membership and roles providers. MVC has complete access to the existing data cache and output cache, as well as the existing data providers. Developers can mix and match any of these other features of ASP.NET with the MVC framework.

To support MVC's coexistence with ASP.NET, MVC looks to flexibility as a primary design goal. MVC is intended to be customizable all around. For example, the code generated by Visual Studio for an MVC-based application includes a standard routing table for helping the application figure out how to handle requests. Although the out-of-the-box routing mechanism works fairly well most of the time, it might not be the best for all situations. Changing the routing policy is relatively straightforward in an MVC application.

By moving all of the MVC routing architecture into the controller, you can easily swap routing policies. This leads to some distinct advantages over typical ASP.NET development. For example, the MVC URL mapping keeps strange URLs hidden from the end user. URL mappings are pushed into the framework, so you can spare your users from seeing messy URL names. Strange URLs, such as /contacts/edit/3256, can be mapped cleanly and internally. At first glance, this might seem like a small feature. However, it does help clean up Web UIs when long, ugly URLs can be stashed away, making room for some very clever routing scenarios. For example, applications using the MVC framework do not need to include extensions, which makes it easy for MVC to support naming schemes for Search Engine Optimization (SEO) and Representational State Transfer (REST) for services.

The MVC framework still uses existing ASP.NET file types, such as .aspx files, .ascx files, and .master files. MVC uses these markup files as view templates. They support the same inline coding syntax (that is, <%= %> snippets). However, rather than each interaction posting back to the server directly, MVC routes interactions to a Controller class. This makes MVC applications much easier to test in the general sense, and to use specifically with test-driven design (TDD) techniques if you prefer. Classic ASP.NET Web Forms by their very nature cannot directly support automated unit testing.

Finally, all the other features of ASP.NET remain intact while using MVC: The cache is still there, output caching is available, session state still works, the provider architecture is still there, and configuration works the same.

3. ASP.NET MVC vs. Web Forms

The ASP.NET MVC framework is fundamentally different from ASP.NET Web Forms. MVC makes a very clear distinction between data sources, program interaction with the data, and the presentation of data. MVC enforces a separation of concerns, whereas that sort of separation is something you'd have to build into an ASP.NET Web Forms application explicitly.

MVC eschews some of the other features of standard Web Forms. For example, ASP.NET MVC does not support view state directly (that feature really stems from server-side controls). As a result, you won't see any hidden fields showing up in pages rendered by the MVC framework.

One of the most prominent places you'll notice that MVC differs from Web Forms is in the area of handling postback events. In MVC, events are routed through a routing table rather than through the singular server-side controls. With Web Forms, however, routing typically occurs through specific event handlers placed on a page.

The MVC framework distinguishes between data, presentation, and program logic, allowing for more isolation between components. This leads to easier testing and debugging. In fact, the ASP.NET MVC framework supports test-driven development very well. This becomes a huge advantage for projects built and supported by large teams.

Because MVC does not rely on certain features, such as view state and server-based controls, more onus is placed on the developer to produce correct HTML. Although this means more responsibility for the developer, it also gives developers much more direct control over how the HTML is rendered.

Finally, ASP.NET Web Forms and server-side controls handle specific events, making it difficult to follow the execution path of a Web Forms–based application. MVC differs significantly because all requests pass through a single point in the application—the routing table. With use of a routing table, developers can control request routing at a single point rather than at ad-hoc points on the page (that is, the event handlers).

4. MVC and Testing

The MVC framework's separation of functionality into specific areas of responsibility makes testing MVC applications much easier than is testing of Web Forms applications. Although the Web Forms model clearly improved the Web programming paradigm for Microsoft developers by separating the concerns of presentation (user interface) and program logic, the Web Forms model still mixes several other concerns. Data access is usually mixed right in with the rest of the program code. For example, if you code your own authentication scheme, you might perform a user lookup directly when a postback occurs because the user clicked the login button. The lookup code is usually right there in the code-beside file. As another example, requests are routed directly back to the .aspx file that's in play. Without MVC, there's no way to perform any alternate routing.

The MVC framework separates these other concerns, making for a much more modular architecture that accommodates unit testing. Testing typical ASP.NET programs usually means clicking through all the controls and UI elements on a page to make sure they work. Then, when something doesn't work, you need to track it down and fix it. The MVC framework supports test-driven development where you define the requirements of code first, and even write test cases prior to writing the code. At that point, you can run user interactions in the MVC framework individually without running the entire application. With this capability, you can unit test individual parts of the application using any of the currently available testing frameworks, such as MS Test and NUnit.

Video tutorials
- How To Install Windows 8

- How To Install Windows Server 2012

- How To Install Windows Server 2012 On VirtualBox

- How To Disable Windows 8 Metro UI

- How To Install Windows Store Apps From Windows 8 Classic Desktop

- How To Disable Windows Update in Windows 8

- How To Disable Windows 8 Metro UI

- How To Add Widgets To Windows 8 Lock Screen

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
programming4us programming4us