The main thing to understand here is that Web Forms (or the code behind the Web Forms) have to execute each time a request comes from the user . They process the request and then terminate. This makes things like module-level variables unusable for storing data that must persist for the entire session. Ah! A new word, session. Web applications use something called session state to maintain context between requests . The session state is maintained by IIS itself, so we don't have to worry about the program terminating and losing its data.
The session exists outside the memory space of the executing code, so it is not lost. There is an intrinsic object called the Session object that is accessible from any Web Form's code that can be used to store persistent session data. A session is defined as the time span between when the user first loaded a page within the web application and when the user jumps to a page outside the scope of the application. This could be to another server or to another application on the same server. Usually once the user loads a page from another web site, the session is considered terminated . Since your web server has no way of knowing that the user has left, this is usually handled by a timeout. So it is possible for a user to leave a site and then return right away (within the timeout) and retain session state. The session timeout is usually pretty longsometimes as high as 30 minutesso the user doesn't lose the session while still using the application. In a typical intranet or secure site it will usually be shorter, because the user is expected to be more active on the site. If you've ever left a page on the screen and then returned, and it made you reauthenticate, you probably hit the session timeout.
All this is important to understand because Web Forms have to recreate themselves every time the user sends a request to the server. The life cycle of a Web Form is diagrammed in the drawing in Figure 9.1. Fortunately, there is a property of the form that you can use to determine if the form is executing for the first time or if it is a PostBack. A form is a PostBack if it has already executed and the user did something without leaving the site that made the form rerender itself. It is important to note that even with a PostBack, the form still must reexecute and restore all of its state data. That is one very useful function of the IsPostBack property. If it is a PostBack, you must retrieve all the data you stored in Session variables or in cookies on the user's machine.