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.
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.
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.
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.