ASP.Net versus ASP.Net MVC

In ASP.Net

Despite the fact that the .Net environment has been around for 10 years now, there is still a considerable number of websites that are running classic ASP with the Visual Basic 6 syntax. As a trainer, I still get questions about what technologies to use when my students are facing rewrites of existing sites. In this article, I will explain the general approaches between the two major contenders from Microsoft: ASP.Net and ASP.Net MVC.


ASP.Net is a wonderfully productive toolset. If you need to whip up a front end to an existing database, you can drag, drop, and set properties on a rich set of existing controls in order to get the functionality you need. The controls offer a tremendous amount of functionality, particularly template controls like the GridView control. These controls allow the developer to customize the presentation of data to a significant extent. Would you like one of your columns to present a dropdown list of choices when it is being edited instead of just a regular textbox? Little to no programming required, just configure a template column in the GridView with the appropriate functionality.

Although there are straight HTML controls available with ASP.Net, developers are encouraged to use what are called Server Controls. If you were to look at the HTML markup for these controls in Visual Studio, you will see that the markup is not valid HTML. Instead, when the page is processed on the server, the ASP.Net engine translates the Server Control markup to valid HTML on the fly. Some server controls correspond directly to HTML equivalents. For example, a TextBox control translates directly to an input type=”text” HTML control. Other controls, like the previously mentioned GridView, are much more complicated, generating a complex mix of HTML, Javascript and style settings on the generated page. Microsoft has gone so far as to have some server controls vary the generated HTML and Javascript depending on the client’s browser, so that that controls function appropriately for each browser family.

In ASP.Net 2.0 (Visual Studio 2005), Microsoft introduced a number of important enhancements to ASP.Net. The most significant of these was the introduction of Master Pages. A Master Page is used to control the layout and basic style of multiple pages in a site. Individual content pages simply plug content into placeholders in the Master Page. A typical Master Page will contain elements for the header and footer, and the content will be plugged via the content page to deliver a complete composite page for use by the user.

Microsoft has implemented its own styling mechanism in ASP.Net, called Themes. Using themes, you can change the style and appearance of the various server controls on a control-by-control basis. You can have a general control for most TextBoxes, for example, and a specific named theme for select TextBoxes that either adds or removes styling elements. Theme settings go beyond the capabilities of traditional CSS; for example, the GridView can have different background colors for alternate rows to give a greenbar paper effect. Themes can also work in conjunction with traditional CSS styling elements, and if there is a conflict between a theme setting and a CSS setting, the developer can choose which overrides the other.

I’ve really just touched the surface of all the rich functionality that ASP.Net provides. The ability to do authentication against either an existing Active Directory domain or a custom database of usernames and passwords, authorization to control which groups of users have access to which parts of the site, profiles to store information for individual users, caching, data binding, and many other features make ASP.Net a very powerful, very productive environment.

ASP.Net Challenges

Despite all of this functionality, Microsoft has been losing market share on the Internet steadily ever since the introduction of ASP.Net. The question is, why? Sure, Microsoft’s development environment has generally required an up-front investment, but that changed with the free versions of Visual Studio (the Express editions) that provided most of the functionality of ASP.Net for no charge. The other side to that argument, as any good IT manager will tell you, is that it is worth investing in a good toolset if it allows their developers to be more productive.

My opinion is that the answer is composed of two parts: performance and a server-centric focus. Let’s dig a little deeper.

On the performance side, Microsoft made the initial decision when developing ASP.Net to make the development experience as much like programming applications for the Windows operating system (Winforms) as possible. In other words, a button object on an ASP.Net form has a click event, just like a button on a windows form. The code to handle the event is very similar, with the same numbers and types of parameters handed to each event. In order to make the two environments work similarly, Microsoft implemented a hidden control on each page generated by ASP.Net called the ViewState. The ViewState contains a version of the web page, as understood by the ASP.Net engine, before the page is modified by user interaction. The ViewState decreases performance in two significant ways. First, there is more information embedded into the page, making the bandwidth used by ASP.Net pages significantly greater than the same pages written with competing technologies. Second, every time a page submitted by a user for processing, the ViewState information is parsed, and the two states of the page (the “before” view as stored in the ViewState and the “after” view as submitted by the user) are compared to check for any differences. This needs to be done so that the proper events are fired in the proper order, which makes things very nice for the developer. However, all that parsing and comparison takes server CPU time, which impacts performance.

Now, before we criticize Microsoft too harshly for this architecture, let’s try to get a larger perspective. I tell my students that I generally have no problem having the computer work harder to make my life easier. I can sleep well at night with that kind of a tradeoff, because it allows my work hours to be much more productive. Making web programming look and feel like Windows programming is a legitimate approach to development. After all, if this argument were not true, we would still be writing code in assembly language instead of higher level languages like Visual Basic and C#.

Another point: it is certainly possible to scale a website using ASP.Net. SharePoint, for example, is built on the foundation of ASP.Net, and most SharePoint installations that face the internet have between 2 and 10 servers to handle the load. ASP.Net has facilities to allow a website to scale over multiple servers as well, with a bit of care taken by the developer. And if the site is an internally facing site, one server is usually quite sufficient to take care of the job in all but the largest organizations.

So if performance is adequate, that leaves the server-centric focus of ASP.Net. And this, I believe, is the real Achilles heel of this development environment, particularly for the Internet.

In ASP.Net, Microsoft’s philosophy has been to perform as much work as possible on the server. When a button is clicked, when a selection is made from a dropdown control, ASP.Net has promoted a philosophy of submitting the page back to the server for processing. Don’t worry about what happens in the browser. Let the server do the heavy work. That’s what servers are designed to do. ASP.Net’s approach seemed to try to avoid JavaScript functionality on the client as much as possible. Cover it up, hide it with controls and tools provided my Microsoft. ASP.Net has treated JavaScript as the redheaded stepsister. JavaScript is ugly, JavaScript is awkward, JavaScript doesn’t work like other object-oriented languages.

Developers, however, have taken a different view. JavaScript has allowed an explosion of functionality to be implemented on the client side. Pages can dynamically update themselves with different content from multiple remote data sources based on user interaction. The Internet is moving into a stage where more and more functionality is being designed around the browser, with servers being relegated to storing/retrieving/managing raw data.

Most developers with a bit of creative flair, which working with ASP.Net, very quickly found themselves running into roadblocks. For example, in order to manipulate the HTML from an ASP.Net page using JavaScript, they first had to understand the HTML being generated. That information was never displayed in Visual Studio, only the fake ASP.Net server markup code. So a developer had to view the generated page in a browser, then painstakingly discover the generated HTML code that they wanted to manipulate in the browser, then go back to the server and try to add the appropriate JavaScript code to interact with the generated HTML.


ASP.Net MVC is Microsoft’s solution to these frustrations, and it is a very good one indeed. The industry will tell you that MVC stands for Model View Controller, a design pattern for implementing web pages that separates the Model (the data and business rules managed on the server) from the View (the appearance of the page), using the Controller as the orchestra conductor to interact with the data from the Model and use it to generate an appropriate View. Fine. That’s true. But it misses the bigger picture.

The bigger picture is that the MVC design pattern allows the developer to have explicit, fine-grained control over all aspects of the HTML being generated and sent to the browser. Using ASP.Net MVC version 3 and later, there are two possible view engines that can be used. There is the traditional WebForms engine which uses all the Server Controls and the ViewState, as with traditional ASP.Net. There is also a new view engine called Razor, which will feel quite comfortable to a developer migrating from ASP classic (non- .Net). The Razor engine allows Visual Basic or C# to be intermixed with the HTML to control the generation of the HTML.

Using the Razor engine, the developer controls what is generated, how it is generated, and with that knowledge implementing JavaScript functionality against web pages becomes very easy. The MVC pattern also allows the easy addition of popular JavaScript libraries for adding functionality to a web page – in fact, ASP.Net MVC ships with a couple of very popular JavaScript libraries, that were not developed at Microsoft, right out of the box.

Using ASP.Net MVC, it is much easier to develop sites that implement a browser-centric focus. Fetching data from the server from the web page in a variety of formats is not only allowed, it is encouraged. Implementing functionality in JavaScript instead of Visual Basic or C# is quite simple. The developer has all the power of the server and all the customizability of the client, and can choose how to divide responsibilities between the client and server in the way that is best for the job at hand.

Data fetched from the server can be in several popular formats. The server can provide chunks of pre-formatted HTML that simply are injected into containers on the existing web page. Or, raw data can be supplied in XML or JSON format, to be manipulated and plugged into the appropriate sections of the web page as desired using JavaScript.

Performance is also improved using the Razor view engine, because there is no ViewState to bloat bandwidth and increase page processing time. Web page sizes are minimal, and with the JavaScript support, the developer can always request additional data from the server after the page is loaded based on user interaction.

Also, much of the existing functionality from traditional ASP.Net has been carried over into the ASP.Net MVC environment. The authentication and authorizations subsystems are still available to authenticate against Active Directory accounts or a database of usernames and passwords. Caching is available. The MVC environment implements master page functionality for both view engines. It really seems to be the best of all worlds.

So with all this functionality and customizability, what is the downside? The biggest downside is the learning curve for existing developers. However, with the choice of view engines, and the ability to leverage either Server Controls or using hand generated HTML, the flexibility of the environment is wonderful. It just takes some education to be able to learn the capabilities of the various environments and decide which approach is best for a particular situation.

If you find yourself in a situation trying to decide how to migrate an existing ASP classic (non- .Net) site to newer technology, I would encourage you to take a good, close look at ASP.Net MVC. You can get started by downloading the free Visual Web Developer 2010 Express edition, which includes most of the ASP.Net and ASP.Net MVC functionality for no charge.

To learn more about Microsoft .Net MVC and Web Forms applications, take a look at the MS10264 – Developing Web Applications with Visual Studio 2010 course scheduled at LRS Education Services.