An Introduction to Web Forms

Web Forms (and ASP.NET in general) is a server-based technology—that is, all your code runs on the server. The client—the application’s user interface—is the user’s browser. The sequence goes something like this: First the user requests your Web Forms page. The browser then sends the request to the Web server (IIS), which calls on ASP.NET to process the page. The page’s output is an HTML stream that’s sent to the client, where it’s out of your hands until the next time the user sends it back to you.

This is quite different from a Windows Form, in which you have complete control over how the form is displayed. In a Windows Form, your code runs in the client (the window) and you can monitor many different events while the user works, reacting more or less instantly to any user action. In a Web Form, the user interacts with the form in the browser by typing and clicking. It’s only when the user has finished and clicks a button (typically) that the page is posted back to the server, where your code can run again.

Server-based processing has a number of advantages for Web applications. You already know that server-based processing allows you to use C# and

the .NET Framework. Another important advantage is that the code is client-independent—it runs the same way no matter what type of browser your users might be using. (In contrast, trying to write a Web application that’s client-specific can get complex, often involving multiple versions of the same page.) Yet another advantage is that your code is on the server, safe from scrutiny by users. When the code runs, it renders ordinary HTML, so users never see your code. Finally, when your code runs on the server, it has access to all the other resources that the server has access to, such as databases, message queuing, and other Windows facilities.

Because your Web Forms code runs on the server, the form has to be posted back (submitted) to the server for any of your processing to happen. Therefore, Web Forms controls generally post the form back so that it can be reprocessed. In addition to using buttons, you can set list box, drop-down list, check box, and radio button controls to post back a Web Forms page.

Perhaps you can see the implication: the Web Forms page makes a round-trip to the server each time the user clicks a button, as shown in Figure 20-1. Compared to performing this action in a Windows Form, this is a comparatively expensive proposition in both time and processing resources. There’s really no other choice, however—if you want to respond to the user’s selection in a list box, the form needs to be sent to the server so that ASP.NET and your code can handle it.

Figure 20-1.

The Web Forms page performing a round-trip to the server.

Posting forms to the server is an inherent part of all Web processing, not just ASP.NET. In fact, an advantage of Web Forms is that it handles a great deal of the work required to perform and process the information sent back and forth with each round-trip.

When ASP.NET gets a page request, it processes the page and your code, renders the page, and then discards it. If the user posts the page back, ASP.NET starts the process all over again: fetch, process, render, discard.

This might seem inefficient to you—if the user might post the page back, why not keep the page handy? The answer, again, has to do with the nature of how Web processing works. The Web is inherently a disconnected environment—the client and the server don’t stay in continual contact. Instead, the client and the server communicate only long enough to exchange information. This model makes perfect sense for HTML pages, where the user might request a page from one Web site, spend some time reading it, and then perhaps jump to another Web site altogether. There’s no good way (or reason) for the first Web site to maintain contact with the user until he or she moves to the next site.

At this level, Web Forms are really no different from HTML pages. The user requests a Web Forms page, and then who knows what the user might do next. To be efficient (in a counterintuitive sense), therefore, ASP.NET “discards” a page as soon as the page has been processed, freeing itself to handle the next request in the queue. (In fact, ASP.NET does cache pages it has processed because Web Forms pages are often posted back and reprocessed. Regardless of what ASP.NET does under the covers, however, you should treat Web Forms processing as if the page were being created from scratch each time.)

The fact that the page is regenerated each time has implications for how you program. For example, the page’s initialize and load sequences run each time the page is requested. Controls on the page are reinstantiated with every round-trip. Remember that the page is requested not just when the user types in the page’s URL, but each time the user clicks a button or performs another action that causes a postback. Compare this to a Windows Form: it’s as if the Load event were fired and the controls re-created each time the user clicked a button.