Introduction

In April 2010, Microsoft will be releasing the next version of Visual Studio, .NET, and the ASP.NET frameworks. ASP.NET 2 will be among these next releases (though the release for Visual Studio 2008 has already been released). ASP.NET MVC is still a maturing product, featuring a whole new set of features that greatly enhance a developer's capabilities. In this article, we'll begin examining the new features of ASP.NET MVC 2.0 by comparing what ASP.NET MVC offers against its predecessor, ASP.NET web forms.

It is important to note that web forms is still a valid option for developing web applications; web forms is still being supported by Microsoft, yet ASP.NET MVC is another product offering for those seeking an alternative way to develop applications.

Nature of the Frameworks

When ASP.NET 1.0 was released, there was great anticipation for the type of changes that were going to be available to developers who could get away from the server-side scripting language of ASP. No longer does a developer's code have to intermingle in the same file as the HTML/server code. The markup could exist in an ASPX page, and all of the logic resides in a separate code-behind file with a suffix of ASPX.CS or ASPX.VB. Server-side controls make available objects that the code-behind file to interact with (label, textbox, and other controls).

This code-behind file has a series of events that fire, allowing your code to be processed in an orderly fashion. The developer can respond to UI events (button clicks, drop down selections that post back to the server, hyperlink redirects). The developer has access to all sorts of utilities to cache data and retain it across page postbacks, as each request to the server is unique and stateless.

Lastly, ASP.NET provides a lot of services already in-built into the framework so you don't have to worry about it. ViewState retains data across postbacks for you, so you don't need to store data within textboxes, selected items within a drop down, check options within the checkbox, and more. Form data gets validated to ensure the user didn't submit any HTML (and potentially any XSS script or injection attacks). The current scroll position is saved and retained across postbacks.

Code Behind vs. Controllers

ASP.NET MVC's version of the code-behind file is the controller class. The controller class works differently however; with ASP.NET MVC, there aren't any server-side controls, page lifecycle, and some of those other familiar page components that web forms developers are used to. Take a look at a sample code-behind page, in listing 1.

Listing 1: Sample ASP.NET Web Forms Page

Here we have a page that pulls the first and last name from a session variable that stores a UserInformation object across page requests. Next, the code-behind invokes a method in the data access layer to get orders for a specific user by its ID, and binds them to the grid. So, in this simple example, the code-behind file is responsible for assigning values to the individual controls in the page, for loading data into a grid, and for communicating with the data access layer. With MVC, we see the alternative controller approach.

Listing 2: Sample ASP.NET MVC Controller

There are some quite substantial changes between this MVC controller and the previous ASP.NET web form. First, the CustomerModel class contains the actual data that gets displayed in the view. In the web form, the code-behind file assigns the data to the view; in MVC, this responsibility will be shown later. Additionally, the controller creates this model for the view, as well as does the data access dirty work, and accessing the data from the session.

So how do we work with textboxes and grids and those other controls we have been so used to working with? Below in Figure 3 is a sample MVC view that displays the UI.

Listing 3: Sample View

There are quite the changes than web forms developers are used to. The MVC view takes over more of the ownership of displaying the data within the UI. It does look similarly to the way web forms works, with the addition of the view specifying the data to load, and the view taking over how the UI will appear without the involvement of a code-behind file.

One simple view of how functions change is the way the GridView in Listing 1 shows a Yes/No value in the last cell. In the last cell, the GridView translates a Boolean value to a Yes/No value using code. This may be common code to a web forms developer, for Booleans and other types of data too, to write code in the code-behind to perform data conversion. In MVC, this data conversion happens inline, without the need to add an event-handler, ensuring that the row is the correct type, and doing the data conversion separate from the UI. Obviously, this isn't a huge deal, but does illustrate simply the differences between the two approaches to rendering data.

Resources

In ASP.NET web forms, developers used a wide array of external resources to store data with. Users could leverage mechanisms like Session, Cache, Application, and other collections for storing data across page postbacks. ASP.NET MVC still uses these to retain its data, but this has gotten better.

With ASP.NET dynamic data came a System.Web.Abstractions assembly, chock full of base classes for every major component like Session, Cache, Request, Response, and the like. Each of these base classes appear as HttpContextBase, HttpRequestBase, etc. This is great for developers because ASP.NET implements a class for each of these (named HttpContextWrapper, HttpRequestWrapper, etc) to provide the actual services. For testing purposes, you can create your own test class that inherits from HttpContextBase or these other base classes.

In web forms, accessing the page's Request property returns a reference to HttpRequest, a non-extensible class highly-coupled to the web forms framework. Conversely, the request object is an HttpRequestBase class reference in MVC, which the ASP.NET MVC framework uses the HttpRequestWrapper implementation to use the actual underlying HttpRequest object; however, for testing purposes, you can create a class that inherits from HttpRequestBase, a fake, that implements test methods that allow you to test your code in NUnit, MBUnit, or other testing framework.

LifeCycle

With ASP.NET web forms, the page fires an Init, Load, PreRender, and Unload events (to name a few). ASP.NET MVC, however, doesn't leverage this lifecycle; instead, it runs requests to action methods (usually one, but other action methods can run additionally through some helper methods). This can be a culture shock to developers who are used to the web forms framework.

Conclusion

ASP.NET MVC is a paradigm shift to how the web forms framework works. This article illustrates the differences between the two from a code- behind and UI framework.

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.

---

Discussion

Subject	Author	Date
Nice explanation..	Asif Iqbal	3/23/2010 10:38 AM
I am very new in ASP.NET MVC and couldn't find any difference between them. But this article might some useful for me. Thanks man! Reply | Permanent link
Wow Brian, you're on top of things!	Wash Caps	4/3/2010 5:16 PM
Thanks Brian, I enjoyed your article.  I just downloaded the latest MVC and have been digging the new framework. Reply | Permanent link
I liked it!	Ly Abdou	5/3/2010 1:20 PM
keep it up man. Young retired developer! Reply | Permanent link
A couple of typos here	Tommy Skaue	8/26/2010 8:11 AM
There are a couple of places where you write "ASP.NET 2" when it should say "ASP.NET MVC 2". It can be a little confusing, since ASP.NET comes in both WebForms and MVC. Good article never the less. Reply | Permanent link

---

Please login to rate or to leave a comment.