ASP..NET Page Processing

One of the key goals of ASP.NET is to create a model that lets web developers rapidly develop web forms in the same way that Windows developers can build made-to-measure windows in a desktop application. Of course, web applications are very different from traditional rich client applications.

There are two key stumbling blocks:

Web applications execute on the server: For example, suppose you create a form that allows the user to select a product record and update its information. The user performs these tasks in the browser, but in order for you to perform the required operations (such as updating the database), your code needs to run on the web server. ASP.NET handles this divide with a technique called postback, which sends the page (and all user-supplied information) to the server when certain actions are performed. Once ASP.NET receives the page, it can then fire the corresponding server-side events to notify your code.

Web applications are stateless: In other words, before the rendered HTML page is sent to the
user, your web-page objects are destroyed and all client-specific information is discarded. This model lends itself well to highly scalable, heavily trafficked applications, but it makes it difficult to create a seamless user experience. ASP.NET includes several tools to help you bridge this gap; most notable is a persistence mechanism called view state, which automatically embeds information about the page in a hidden field in the rendered HTML.
In the following sections, you’ll learn about both the postback and the view state features.

Together, these mechanisms help abstract the underlying HTML and HTTP details, allowing developers to work in terms of objects and events.