Programming Microsoft ASP.NET 4 - Dino Esposito [7]
Lightweight Pages
The view state is a fundamental element of the ASP.NET puzzle because it allows for the simulated statefulness of the Web Forms model. Many developers who recently embraced ASP.NET MVC—the alternate framework for ASP.NET development fully integrated in Visual Studio 2010—still find it hard to understand that each view can have shared data that must be refilled even though nothing in the request processing happened to modify it. More simply, it is the lack of view state that keeps any UI element (grids, drop-down lists, and text boxes) empty until explicitly filled on each and every request.
The view state has always been a controversial feature of ASP.NET. Starting with ASP.NET 2.0 (some five years ago), however, Microsoft introduced significant changes to the internal implementation of the view state and reduced the average size of the view state hidden field by a good 40 percent.
The view state is functional only to an application model extensively based on server controls and using server controls extensively to generate HTML. At a time when architects question the applicability of the classic ASP.NET model to their applications and look for more client-side interaction, separation of concerns (SoC), and control over the markup, the view state feature—a pillar of ASP.NET—is not that significant. Hence, it is now, more than ever, perceived as deadweight to get rid of.
Important
More and more applications require pages rich with client code that limit the number of postbacks and replace many postbacks with AJAX calls. In this context, Web Forms can be adapted—maybe even to a great degree—but the approach has some architectural limitations that must be known and taken into account. These limitations are not necessarily something that would make you lean toward an alternate framework such as ASP.NET MVC, but they also are not something a good architect can blissfully ignore.
How Much Is the Framework and How Much Is It You?
Introduced a decade ago, ASP.NET Web Forms has evolved and has been improved over the years. Its flexible design allowed for a lot of changes and improvements to be made, and the framework is still effective and productive. Although the design of the ASP.NET framework was inspired by a totally different set of principles and priorities than the ones you would apply today, most of the alleged limitations of ASP.NET that I’ve outlined so far (heavyweight pages, limited control over markup, lack of testability) can still be largely worked out, smoothed over, and integrated to serve up an effective solution. This is to say that the advent of a new framework such as ASP.NET MVC doesn’t necessarily mean that ASP.NET Web Forms (and, with it, your existing skills) are out of place. There’s always a strong reason for new things (frameworks in this regard) to be developed, but understanding needs, features, and capabilities is still the only proven way of dealing with hard decisions and architecture.
ASP.NET Web Forms is designed around the Page Controller pattern. Let’s find out a bit more about the pattern and what you can do to limit some of its current downsides.
The Page Controller Pattern
The ASP.NET Web Forms model resolves an incoming request by dispatching the request to an HTTP handler component. (An HTTP handler component is simply a class that implements the IHttpHandler interface.) According to the ASP.NET Web Forms model, the HTTP handler is expected to return HTML for the browser. (You’ll find out more about HTTP handlers in Chapter 4.) The way in which the HTML for the browser is prepared is strongly oriented to the creation of a Web page. The pattern behind this approach is the Page Controller pattern.
The pattern envisions the processing of a request as a task that goes through a number of steps, such as instantiating the page, initializing the page, restoring the page’s state, updating the page, rendering the page, and unloading the page. Some of these steps have been rendered in Figure 1-2, and all of them