With the introduction of ASP.NET 1.0, an ASP.NET web page had the option of posting back to itself. How postbacks work is that each time an ASP.NET web page is requested, a series of events that follow an ASP.NET page's life cycle fire off in a well-defined order. Figure 10-1 outlines the life cycle of a typical ASP.NET page.
The great thing about postbacks is that they allow the developer to use view state to maintain data collected from the user on each postback to the same page. Developers can also use this data during the page's postback process as long as they do so when it is accessible, which is defined by the page life cycle. A simple example of this is when a user fills out a feedback form. When he's finished, he clicks the Submit button. The data collected from the user is then sent to the server, which may do validation on the data. If the data does not meet requirements set by the developer, a flag can be set to postback the page with the error message presented to the end user. This, with the combination of view state, allows the page to be re-rendered and the values previously collected from the user can be bound to the controls where the user already entered the data. This makes for a better end-user experience because it keeps the user from having to input all of the data a second time.
View state is encrypted on the server side before being passed to the client and is then decrypted on the server side as well when needed again.
The downside of postbacks is that each time a postback is required, the entire page life cycle must be iterated through and the page reproduced. This not only increases the workload on the remote web server, but it also increases the time end users must spend for this to be processed and returned to them with the error message. In addition, it increases traffic across the network because after the users are presented the page for a second time and they make their corrections, the page must be processed on the server side a second time, plus each control exposing itself to the view state must pass the collected data to and from the server on each postback. Although this is a simple example that can be completely avoided using one of ASP.NET's built in client-side validation controls, not all situations are quite this simple.
When Microsoft introduced ASP.NET 2.0, one of the embellishments was the capability to postback to other pages and not just the same page. This allows data to be passed from one page to another without sending the data to the data store before moving to the next page, or requiring the developer to use query string parameters containing the values gathered on the first page but needed on the new page. This is accomplished using the view state embedded in a hidden input field named __POSTBACK, which is passed from the first page to the new page. This field is embedded only when there is an IButtonControl on the page and its PostBackUrl property is set to a non-null value. To access the view state of the first page, the developer can use the PreviousPage property on the new page.
A detailed explanation of the page life cycle and view state are far beyond the scope of this chapter. If you require more information on either of these topics, refer to the MSDN web site or Visual Studio's MSDN Library. The basics covered in this section are here to give you a briefing on these items so you can understand other sections of this chapter.