A lot of fuss is being made lately about whether Microsoft’s relatively new Model View Controller (MVC) technology should automatically supplant .NET Web Forms as the superior web application development technology. There is no clear-cut answer, and rightly so; they both provide different means to reach the same end. Different customers look for different programming approaches, and a lot love Web Forms and think it is great. Others love MVC and think it is great. That is why companies are investing in both. Below, I have tried to highlight some positives and negatives of both frameworks. This is not an attempt to sway you one way or the other, but rather to possibly provide a broader understanding of why the two frameworks exist as viable options for your company’s development needs.


What Are .NET Web Forms?

The idea of .NET Web Forms was born from an attempt to address the ever looming issue implicit in the development of classic ASP websites. Classic ASP pages housed both the web code and the accompanying code-behind logic in one location: the ASP page. In that way, pages could very easily become long spaghetti-code filled documents that often would become unreadable and unmaintainable. For example, the code to handle page submissions was contained on the same page that would subsequently either redirect the user or need to remain on the current page, but would simply show a different section of the page. This type of event handling was unwieldy.

To address this concern, Microsoft attempted to bring their successful, more event-driven, “visual” windows-application development methodology to web development. As a result, they created a framework that worked more like the popular Visual Basic or Visual C++ desktop/forms development. Suddenly, developers could decouple view code from logic code by having most of their web controls on one page and then have all of the code-behind, “smarts” of the page, contained in a completely separate page.


Advantages of .NET Web Forms

  • RAD – Rapid Application Development
    • The mechanisms behind how controls and pages work within an event-driven structure are abstracted out so that the developer generally does not need to know the inner workings of the process
    • Drag & Drop controls provide most of the functionality right out of the box. 3rd party solutions are readily available, and control like Grids generate the HTML and JavaScript for the developer
    • Applications, complete with validation, can be quickly developed by simply setting properties on controls
    • Easy for newbies to “pick up and run” with web application development
  • Cost
    • Being the older, more legacy framework, most .NET web developers have experience with Web Forms, or more specifically the desktop application event driven framework from which it was derived – there is a smaller learning curve implicit in learning the Web Forms framework
  • More Mature
    • Like the old joke goes, “no matter how old you are I’ll always be younger”. Even though MVC is a younger .NET technology (the paradigm methodology, though, has been around for a while), Web Forms was here first and has a larger and more robust legacy implementation


Disadvantages of .NET Web Forms

  • Very little control over HTML produced on the page
    • The ability to simply drag & drop controls enables rapid application development (RAD), but the drawback is that the developer has very little control over what HTML is actually produced on the page
    • Initially, a pretty big issue with Web Forms was not being able to control the HTML produced on the page, meaning that control ID generation was sometimes after-the fact guess work
      • ID management becomes compromised and using client side frameworks like jQuery become more difficult in that control ID’s, or even control nesting/hierarchies, are not always consistent
      • Even though Microsoft has taken steps to improve this in the latest release of MVC, not enough time has passed to determine if they’ve truly resolved this issue
  • Web Forms Life Cycle
    • How many developers truly know the full extent of the Web Forms lifecycle? A lot of developers must become acquainted with the more esoteric lifecycle events as a result of needing to “hook” into 3rd party controls


What is MVC?

The MVC design pattern was not invented by Microsoft. Rather, it has been around for upwards of 30 years, having been first introduced around 1979. Since then, the methodology has been implemented by such well-known platforms as Ruby on Rails, Apple’s Cocoa and Apache Struts. Only relatively recently has Microsoft added the MVC design, building atop the .NET framework. As a result, .NET developers have the option to develop applications within the existing .NET world they already know but can eschew the lack of overall control offered by the drag & drop of Web Forms. With MVC they can embrace the same separation of concern (SOC) paradigm that has already proven to be successful in other frameworks. Admittedly, not all MVC implementations are exactly the same, with slight differences existing between the different frameworks. For example, Microsoft’s implementation of MVC more closely resembles Rails and Django rather than either Apple’s Cocoa or even the original implementation of MVC, Smalltalk-80.