14 Days Free Technical Video Training from WintellectNOW


Why ASP.NET MVC is different than Classic ASP


There's still a lot of Classic ASP developers out there, maintaining and adding features to existing ASP sites. Many want to migrate or upgrade to ASP.NET, and particularly ASP.NET MVC. During my MVC presentations, the most frequently asked question I get is: "This looks like Classic ASP code, are we just going backwards with MVC stuff?". If we dig into MVC a bit deeper, we'll see that the answer is most definitely, NO. Although at first glance, the mixture of HTML and script in the views may appear to be similar to Classic ASP, upon further investigation, there are some very remarkable differences.

Note: When speaking of Classic ASP in this post, I'm referring to the ASP found in .asp pages, not .aspx Web Forms.

MVC Models & Classic ASP Data Access


There are many options for dealing with data in MVC models; EF (db or code first),  LINQ to SQL, POCOS, Service Layers or even DataSets and DataReaders. No matter what the choice, all data model code is partitioned away from the views and controllers, and that's the important factor to consider. MVC convention and application templates guide the developer to add models to a \Models folder or use a library reference (preferably) the data access layer. As a developer you get full control over where and how you create the data access layer and business objects so it doesn't interfere with UI code.

Classic ASP:

There's two primary ways of dealing with data in ASP. Developers often place data access code directly in the .asp page and other times in a COM component. Data returned from the data access layer is returned into ADODB.Recordset objects which represent the data as a rectangle, and that data is directly sent to the ASP page.

Because of the tight coupling, code in the data access model is harder to test and maintain.

MVC Views & Classic ASP Pages


Views are the reason that prompts developers to look at MVC and think it's similar to ASP, and that's because in the view both HTML and code exist side by side. However, peering into views a bit deeper reveals that views contain only enough markup and syntax to render pages from data that is passed to views from a controller. That means the code in MVC isn't a bunch of large gobs of script interlaced with markup, they're generally just code nuggets. This also means that the most noticeable difference is the lack of actual code itself (hopefully!), as views should be clean and not cluttered.

Classic ASP:

Pages in ASP often contain server script, client script, markup, and the kitchen sink thrown in for good measure. JavaScript obtrusively pilfers the markup throughout entire pages. All too often, the ASP page contains large amounts of business logic code, and everything gets stuffed into big .asp pages.

Although there are techniques for working with ASP to get some separation of concerns, that concept gets offset since most all of today's ASP development is in maintenance mode so many aren't investing in enhancing Classic ASP technology, particularly when there are other alternatives.

MVC Controllers & Classic ASP


Rather than mapping URL addresses to individual static pages living on a web server, MVC uses Routing to map the HTTP request to methods, not complete pages, in controllers called action methods. Action methods retrieves an entity in the model to match the model to a corresponding view based on routing information in the URL. These URL patterns, called Routes, are defined and added to an application wide RouteTable object so the routes can identify and execute controllers automatically. This gives tremendous flexibility, as the controller can behave as a traffic cop, directing requests to a specific code location which is natively more testable than a whole page. This also gives us a nice separation of concerns as well.

Classic ASP:

There's nothing to compare to a controller in ASP as there's nothing out of the box that supports routing in any similar way to MVC. URLS are directly mapped to a an .asp file and there's nothing in the ASP platform itself to help out. You could write an ISAPI filter or some sort of module to create your own routing system, but it's more work and maintenance compared to MVC, as MVC has this functionality built in.


MVC isn't just a rehash of Classic ASP and we're definitely not going backwards in technology with it. MVC gives you a way to write much cleaner, separated,  and robust code. The MVC pattern and ASP.NET MVC project templates in Visual Studio also assist in guiding the developer to do better things with their code, such as unit testing or implementing other practices such as dependency injection (DI), which are hard to near impossible to do in older versions of ASP. The good news: If you're writing ASP applications now, the move from Classic ASP to MVC doesn't have to be such a huge learning curve.


  • Bill44077 said

    Hi Rachel,

    Nice comparison. Thanks for thinking about these pieces and putting them together in one place! Sometimes the best way to explain something to someone is to compare it to something that they already know. Good job!

  • Someone said

    "There's two primary ways of dealing with data in ASP.."

    You mean "There're"?
    Sorry but I get caught up when paragraphs don't read properly

  • Fabio Nagao said

    I disagree with this article, you are very probably with a perspective of Classic ASP from 95... as the web evolved and the good programming paradigms start to pop out here and there, Classic ASP also started to use'em. Take a look in ASP Xtreme Evolution <http://zend.lojcomm.com.br/goodies/asp-xtreme-evolution/> and you will see thats its a perfect MVC Model 2 implementation running in Classic ASP.

  • Rachel said


    Sure, I get that. I've used some of those frameworks myself (or my own) to implement patterns in classic ASP. I didn't mean to imply that nobody uses them.

    My point of the article was to clarify some points due to questions that continually come up during my talks and whatnot by a whole lot of folks who think our ASP.NET framework is just a simple rehash of the classic ASP system. You seem to have a good handle on that already though, and are well equipped to make those architectural choices.

    PS - I've done a lot of non MS web stuff too, just so you have an idea of my perspective as well. (PHP, Java, Perl, just to name some)

    Thanks for the comments. It's always good to have these kind of discussions.

Comments have been disabled for this content.