Comparing Web Forms And ASP.NET MVC
I first saw Microsoft ASP.NET in action in 1999, when it was tentatively named ASP+. At that time, building a Web application on the Microsoft platform was a matter of assembling a bunch of Active Server Pages (ASP).
In a typical ASP page, you find HTML literals interspersed with code blocks. In code blocks, script code (mostly VBScript) is used to incorporate data generated by COM objects, such as components from the ActiveX Data Objects (ADO) framework. Undoubtedly, the introduction of ASP.NET in the late 1990s was a big step forward, as it represented a smart way to automate the production of HTML displayed in a client's browser.
ASP.NET simplified a number of everyday tasks and, more importantly, enabled developers to work at a higher level of abstraction.This allowed them to focus more on the core functions of the Web application rather than on common tasks around Web page design.
So why did Microsoft release "another" ASP.NET framework, called ASP.NET MVC? In this article, I'll explore the pros and cons of both ASP.NET Web Forms and ASP.NET MVC.
Benefits of ASP.NET Web Forms
As noted, ASP.NET Web Forms is stable and mature, and it is supported by heaps of third party controls and tools.
To simulate stateful programming over the Web, ASP.NET Web Forms introduced features such as viewstate, postbacks, and an overall event-driven paradigm.For example, the developer can, say, double-click on a button to automatically generate a stub of code that will handle the user's clicking to the server. To get started writing an ASP.NET Web application, you just need to know the basics of .NET development, the programming interface of some ad hoc components, like server controls. Server controls that generate HTML programmatically, and the runtime pipeline, contribute significantly to a fast development cycle.
To write an ASP page, you did need to know quite a bit about the Web and script languages. To write an ASP.NET page, in contrast, you need to know primarily about .NET and its compiled languages. Productivity and rapid development of data-driven, line-of-business applications have been the selling points of ASP.NET Web Forms. Until now, that is.
Drawbacks of Web Forms
Like many other things in this imperfect world, ASP.NET Web Forms is not free of issues. Years of experience prove beyond any reasonable doubt that separation of concerns (SoC) has not been a natural fit with the Web Forms paradigm.
Automated testing of an ASP.NET Web Forms application is hard, and not just because of a lack of SoC. ASP.NET Web Forms is based on a monolithic runtime environment that can be extended, to some extent, but it is not a pluggable and flexible system. It's nearly impossible to test an ASP.NET application without spinning up the whole runtime.
Benefits of ASP.NET MVC
In many aspects, the Web Forms model in ASP.NET 4.0 is a better environment that tackles some of the aforementioned flaws. So what's the point of ASP.NET MVC?
You'll find a good introduction to ASP.NET MVC in the March 2008 issue MSDN Magazine
("Building Web Apps without Web Forms
"), where Chris Tavares explains the basics of ASP.NET development without Web Forms. In summary, ASP.NET MVC is a completely new framework for building ASP.NET applications, designed from the ground up with SoC and testability in mind. When you write an ASP.NET MVC application, you think in terms of controllers and views. You make your decisions about how to pass data to the view and how to expose your middle tier to the controllers. The controller chooses which view to display based on the requested URL and pertinent data. Each request is resolved by invoking a method on a controller class. No postbacks are ever required to service a user request. No viewstate is ever required to persist the state of the page. No arraysof black-box server controls exist to produce the HTML for the browser.
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
The HTML served to the browser is generated by a separate, and replaceable, engine. There's no dependency on ASPX physical server files. ASPX files may still be part of your project, but they now serve as plain HTML templates, along with their code-behind classes. The default view engine is based on the Web Forms rendering engine, but you can use other pluggable engines such as nVelocity or XSLT. (For more details, have a look at the MVCContrib Web site at mvccontrib.codeplex.com.)
The runtime environment is largely the same as in ASP.NET Web Forms, but the request cycle is simpler and more direct. An essential part of the Web Forms model, the page lifecycle, is no longer necessary in ASP.NET MVC. It should be noted, though, that the default view engine in ASP.NET MVC is still based on the Web Forms rendering engine. This is the trick that allows you to use master pages and some server controls in ASP.NET MVC views. As long as the view engine is based on Web Forms, the view is an ASPX file with a regular code-behind class where you can handle classic events such as Init, Load, PreRender, plus control-specific events such as RowDataBound for a GridView control. If you switch off the default view engine, you no longer need Page_Loador other events of the standard page lifecycle. Figure 1 compares the run-time stack for Web Forms and ASP.NET MVC.
Figure 1 The Run-Time Stack at a Glance (Click the image for a larger view)
It should be noted that the "Page lifecycle" boxes in Figure 1 have been collapsed for readability and include several additional events each. Anyway, the run-time stack of ASP.NET MVC is simpler and the difference is due to the lack of a page lifecycle. However, this makes it problematic to maintain the state of visual elements across page requests. State can be stored into Session or Cache, but this decision is left to the developer.
Figure 2 illustrates the sequence of an ASP.NET MVC request.
Figure 2 The Sequence Diagram of an ASP.NET MVC Request (Click the image for a larger view)
The MVC acronym stands for Model-View-Controller. However, you should note that the pattern depicted in Figure 2 doesn't exactly match the classic formulation of the MVC pattern. In particular, in the original MVC paper, Model and View are tied together through an Observer relationship. The MVC pattern, though, is deliberately loosely defined and, even more importantly, was devised when the Web was still to come. Adapting MVC to the Web moved it toward the model in Figure 2, which is also known as Model2. In general, when you talk or read about MVC be aware that there are quite a few slightly different flavors of it within the literature.
Drawbacks of ASP.NET MVC
So ASP.NET MVC brings to the table a clean design with a neat separation of concerns, a leaner run-time stack, full control over HTML, an unparalleled level of extensibility, and a working environment that enables, not penalizes, test-driven development (TDD). Is ASP.NET MVC, therefore, a paradise for Web developers?
The Right Perspective
As an architect or developer, it is essential that you understand the structural differences between the frameworks so that you can make a thoughtful decision. All in all, ASP.NET Web Forms and ASP.NET MVC are functionally equivalent in the sense that a skilled team can successfully use either to build any Web solution.
The skills, education, and attitude of the team, though, are the key points to bear in mind. As you may have figured out yourself, most of the features presented as a plus for either framework may also be seen as a minus, and vice versa. Full control over HTML, for example, may be a lifesaver to one person but a nightmare to another. Personally, I was shocked the first time I saw the content of a nontrivial view page in ASP.NET MVC. But when I showed the same page to a customer whose application was still using a significant number of ASP pages, well, he was relieved. If you have accessibility as a strict requirement, you probably want to take full control over the HTML being displayed. And this is not entirely possible with Web Forms. On the other hand, if you're building a heavy data-driven application, you'll welcome the set of data-bound controls and statefulness offered by Web Forms.
Correctly, Microsoft has not positioned ASP.NET MVC as a replacement for ASP.NET Web Forms. Web Forms is definitely a pattern that works for Web applications. At the same time, Ruby-on-Rails has proved that MVC can also be a successful pattern for Web applications; and ASP.NET MVC confirms this.
In the end, Web Forms and ASP.NET MVC have pros, cons, and structural differences that affect various levels. Generalizing, I'd say that Web Forms embraces the RAD philosophy whereas ASP.NET MVC is TDD-oriented. Further, Web Forms goes toward an abstraction of the Web that simulates a stateful environment, while ASP.NET MVC leverages the natural statelessness of the Web and guides you towards building applications that are loosely coupled and inherently testable, search-engine friendly, and with full control of HTML.
What's the Perfect Model for ASP.NET?
Going back to the root of the problem, the key difference between Web Forms and ASP.NET MVC is the underlying pattern. Web Forms is a model based on the "Page Controller" pattern. Web Forms are UI-focused and centered around the concept of a page: the page gets input, posts back, and determines the output for the browser. The development environment was therefore devised to enable rapid prototyping, via wizards and rich designers. Any user action ends up in a method on the code-behind class of each page. At that point, though, nothing prevents you from using proper SoC and nothing really stops architects from imposing patterns like MVC, Model-View-Presenter (MVP) or even Model-View-View-Model (MVVM).
The Web Forms architecture does not encourage SoC, but it doesn't prevent it either. The Web Forms architecture makes it seductive to opt for drag-and-drop of controls, to code logic right in event stubs without further separation, and to drop data sources right on the page, which couples the UI directly to the database. MVC is neither prohibited nor a blasphemy in Web Forms; it's just that very few developers practice it because it requires working around much of the Web Forms infrastructure.
Testability is a different story. ASP.NET Web Forms doesn't prevent unit testing, but it requires much disciple and repetitive boilerplate coding to do so.As long as you code your way to SoC you can test and reuse presentation and business logic. Sure, you likely don't have the Visual Studio project template to create a test project for you. You need to become familiar with testing and mocking frameworks and manage those projects yourself. But this can be done. From a testability perspective, though, a real difference exists between Web Forms and ASP.NET MVC. In Web Forms, you just don't have the flexibility of ASP.NET MVC. This is a true limitation. ASP.NET MVC is designed with testability in mind,which means that the framework architecture guides the developer to write code that is inherently testable, that is isolated from the context or connected to it via contracted interfaces. Even more importantly, in ASP.NET MVC intrinsic objects are mockable as they expose interface and base classes. From a testing standpoint, the best you can do in Web Forms is to move your logic into separate and easily testable classes. Then, you test the presentation (ASPX and code-behind) by sending HTTP requests and checking the results. You can't do this in Web Forms without spinning up the whole ASP.NET runtime, however. In ASP.NET MVC, the majority of testing is to assure that the data being passed into the view is correct. In addition, you can mock up intrinsic objects and run your tests in a genuinely isolated environment.
ASP.NET Web Forms and ASP.NET MVC are not competitors in the sense that one is supposed to replace the other. You have to choose one, but different applications may force you to make different choices. In the end, it's really like choosing between a car and a motorcycle when making a trip. Each trip requires a choice, and having both vehicles available should be seen as an opportunity, not as a curse. Here are some facts about the frameworks:
- Web Forms is hard to test.
- ASP.NET MVC requires you to manage the generation of HTML at a more detailed level.
- ASP.NET MVC is not the only way to get SoC in ASP.NET.
- Web Forms allows you to learn as you go.
- Viewstate can be controlled or disabled.
- Web Forms was designed to abstract the Web machinery.
- ASP.NET MVC exposes Web architecture.
- ASP.NET MVC was designed with testability and Dependency Injection in mind.
- ASP.NET MVC takes you towards a better design of the code.
- ASP.NET MVC is young and lacks a component model.
- ASP.NET MVC is not anti-Web Forms.
ASP.NET MVC was not created to replace Web Forms but to partner it. ASP.NET MVC turns some of the weaker elements of Web Forms into its own internal strengths. However, problems such as lack of testability, SoC, SEO, and HTML control can be avoided or reduced in Web Forms with some discipline and good design, though the framework itself doesn't provide enough guidance.
At the End of the Day
We have seen that there are pros and cons in both Web Forms and ASP.NET MVC. Many developers, however, seem to favor ASP.NET MVC because it represents the only way to get SoC and testability into their applications. Is it really the only way? No. However, ASP.NET MVC makes it easier and natural to achieve SoC and write more testable code. ASP.NET MVC doesn't magically transform every developer into an expert architect and doesn't prevent developers from writing bloated and poorly designed code. At the end of the day, both Web Forms and ASP.NET MVC help to build applications that are designed and implemented to deal effectively with the complexity of real-world solutions. No software magic exists, and none is yet supported by the ASP.NET platform.
is an architect at IDesign and the co-author of Microsoft .NET: Architecting Applications for the Enterprise
(Microsoft Press, 2008). Based in Italy, Dino is a frequent speaker at industry events worldwide. You can join his blog at weblogs.asp.net/despos