Web Forms was _very_ different from Classic ASP, which, at the time, was called just ASP. Or ASP 3.0, which had some differences from ASP 2.0, for those who remember. ASP 1.0 was short-lived, and it largely remains a blur between the IDC/HTX technology that graced IIS 2.0, and ASP 2.0, which became very popular.
The programming model of Web Forms was radically different from ASP. In fact, it very closely resembled the programming model of Visual Basic (VB) 6, which enabled the developer to visually position controls or UI elements on a screen and then double-click buttons in order to quickly write some code to execute when that button is pressed. For those who remember .Net 1.0, you will remember that ASP.NET used absolute CSS positioning to emulate grid-like placement of UI elements on the screen. That didn’t last long, and ASP.NET 1.1 changed the default layout to “flow layout”, which is the way the web works anyway.
Let’s review. In the mid-90′s, you programmed dynamic web applications on Windows/IIS servers using code that largely looked like this.
Datasource:ecommerce Template:ListOrders.htx SQLStatement:SELECT * +FROM Orders +WHERE Orders.Status='%OrderStatus%';
From an HTML page, you just made a form that posted “OrderStatus” from a select box to ListOrders.idc. This file executed the SQL statement against the ecommerce DSN registered on the server – most likely hooking into an ODBC data source to a main frame, Sybase, or Access database. The HTX file was the next web page that was rendered and might have looked like this (with some HTML formatting around it, of course.
<%begindetail%> <%OrderId%> <%if CustomerName eq ""%> <%else%><%CustomerName%> <%endif%> <%enddetail%>
We can clearly see the lineage from this, up through Classic ASP, into ASP.NET with Web Forms, as well as through the first two version of ASP.NET MVC. The new Razor view engine with ASP.NET MVC 3 & 4 does away with the beloved and cursed “code nugget” (<%= %>) that started in the mid-nineties with the IDC/HTX technology.
So should I upgrade my Web Forms application to MVC?
I explained the bit of history above so that you would have some context to answer this question for yourself. To answer this question, you should know a bit about the run times.
With Classic ASP, you are likely to have code written in VBScript using COM+ components. It is possible your applications used JScript, but this was more rare, although supported nicely. These applications run just fine in Windows/IIS and in Azure, but you cannot have them run in the same memory space as ASP.NET. .Net was a hard break from the COM world of the late 90′s. Contrast that with ASP.NET 1.0-4.5, and Web Forms, ASMX, ASP.NET MVC, and Web API. All of these technologies can run in the same website within IIS and share the memory. This is very powerful because we are not forced to answer the question of whether to rewrite or not. We can do both. We can keep the Web Forms features and functions that work just fine and add on to the application using ASP.NET MVC and Web API. In fact, some teams are using HTML5 on top of ASP.NET MVC to write touch-based tablet apps that can be synced and used off-line.
It is rarely a good idea to trash your current application and start over. Too much has been invested, and if any of it is working properly and serving the business, then keep it. To keep it, just add onto the code base with ASP.NET MVC. You can rewrite some of the screens if there is a lot to be desired there, but because Web Forms and MVC work seamlessly together in the same web application, it’s a touch sell from a business perspective to write software just to have it behave the same way. If these existing functions need to be exposed to tablets or phones, then it’s fairly easy to create new MVC screens with HTML5 and use some of the same business logic (if well factored), or at least the same database tables with rewritten business logic. If a native phone app is in order, Web API can serve as the HTTP web services to serve and receive data. These web services run nicely integrated with an existing Web Forms application.
There is an estimated 4 million web forms applications and websites out there (and probably many more that are not on publicly indexable web servers – to be counted). Enhancing an existing Web Forms application with the newer technologies can be a powerful way to preserve the deep investments made this far.