Using State in ASP.NET Web Pages

Hopefully, you reached this page from the About Visual Basic ASP.NET Hub Page. If not, you might want to click the link above and go there.

When the a web server sends a response back to your computer (See Server Processing for more on this) everything about your application is flushed from memory. In other words, if the web page was part of a shopping site, everything about what was in your cart is deleted from memory. If it's a search page, the page you searched last and the search term you used is gone. If you're trying to login and you need a password hint, the server has removed everything about the password you just tried to enter from memory. The server actually drops the connection and forgets who you are.

If you think about it, it couldn't work any other way. The server may have to handle hundreds of web requests more or less at the same time and there's no guarantee you will ever hit that Enter key to continue the session. It just isn't possible for servers to keep the information being used by web clients in memory. To solve the problem, a fundamental part of the http protocol itself it's stateless. The "state" of your application is not maintained by the server. This is exactly opposite from the way Windows manages the different applications running on a single computer. Windows remembers everything about an application until the app is closed.

Yet, we know that a shopping site does not lose track of what's in the cart. So how does this work?

The answer is "state management". The server doesn't keep track of state directly, but ASP.NET (and virtually all other web application development technologies) does have ways to do it. That is "ways" - plural. There are actually a lot of different techniques to do this that you, the programmer, can select for your application. In fact, that's one of the problems. Just understanding what your choices are and the differences between them is confusing. For example, you can use both view state and session state to persist (save between postbacks) information and in your code, they look almost exactly the same. If you want to persist the value, "My String", you can do it using either of these statements:

ViewState("theKey") = "My String"

or

Session("theKey") = "My String"

or

Application("theKey") = "My String"

Later, you can retrieve the value using similar code. (Since they're saved using very different techniques, it doesn't matter that the key is the same.)

theViewStateString = ViewState("theKey")
theSessionStateString = Session("theKey")
theApplicationStateString = Application("theKey")

The differences in these two techniques can be critical to your program, however.

One reason state management can be confusing is that different sources explain state management in different ways.

For example, one Microsoft page classifies the various techniques into "client based" versus "server based" state management. State information has to be saved somewhere. These techniques use the client to save state:

• View state
• Control state
• Hidden fields
• Cookies
• Query strings

These techniques use the server:

• Application state
• Session state
• Profile properties
• Database support
• ASP.NET caching

Notice that View state and Session state are in different groups using this classification.

Another classification relies on whether ASP.NET provides actual objects to maintain state or whether it's all up to you to write the code. After all, you might not consider cookies or database support to be state management techniques since it's obvious that you can save information that way. That's what they're for. This classification - and my articles here in the ASP.NET Hub - focuses on the techniques where ASP.NET provides specific state management objects:

1. View State
   If you use an ASP.NET control, such as an ASP.NET Button or TextBox, the properties of these controls are maintained by ASP.NET automatically by default. You don't have to do a thing. So if you put a TextBox into your form and you change the Text property to "My String", you can rely on that property being the same after a round trip to the server. You can read more about View State here.
2. Session State
   Session state gives you more flexibility in telling ASP.NET what to remember, such as setting a timeout and defining different storage options. More about Session state can be found here.
3. Application State
   This is a lot like session state, but it applies to the entire application, not just one user or session. For example, in a multiplayer game, the list of all the players is something the game program needs to remember. Application state is covered in greater detail here.
4. Profiles
   This is "by user" information that you want the application to remember more or less permanently. For example, if you upload an icon to represent you, the application needs to remember that until it's changed. Profiles are introduced in this Hub article.

• Back to the Main Hub Article