he sun is shining and I am sitting at a large, umbrella-covered picnic table overlooking a shimmering pond, my state right now is pretty relaxed. I have been fortunate enough to have spent the last few days at a cabin in the northern part of Maine. The birds are chirping, kids are playing, and there's not a Moose in sight. The only state management I'm concerned with right now is my own state of mind, and right now I am feeling pretty good. State management, whether you are dealing with your own state of mind or if you are working with ASP.NET, is a very fundamental and important task.
In this article I am going to cover the important and sometimes confusing topic of state management. I will explore the state management fundamentals, covering both client-side and server-side state management options.
If you are familiar with Web development then you are well aware that developing Web applications is very different from developing Win32 applications. For those new to Web development I am sure you are finding that there are a number of special challenges associated with developing a Web application. One of the more challenging tasks is persisting state across the application. Before you can persist state across an application, it might help to know what state is.
Quite simply, whether you are building a traditional Windows application or a Web-based application, state is what an application knows about the user, their current interaction with the application, and other pieces of global information. What type of information am I referring to here? Information such as who the user is, where they are in the application, what information they have entered so far, and other application configuration information.
In retrospect, when developing a traditional Windows application, maintaining state wasn't an issue you had to concern yourself with. You probably never gave it any thought at all. Storing information about the current user, their preferences, or information about the current configuration of the application for that matter, was as simple as storing the information globally in either variables or as properties of an object. Those global variables remain in memory for the application to use until the application is terminated or until they are released. Maintaining state information in a traditional Windows application couldn't be any easier. Unfortunately, Web applications are a different story entirely.
Web applications are stateless. A user request is received to display a Web page and a Web server obliges by sending the HTML to the user's browser to displayseems simple enough. It is important to realize that at this point the communication is over until the user requests another page. When the next user request comes in the Web server has no idea who the user is. The Web server doesn't know what pages it has sent before to that user or if the user has ever been sent any page at all. After the Web server processes each user request it wipes the slate clean and gets ready for the next incoming request, be it from you or someone else.
The question is, if the Web server is continually wiping its memory clean after every request, how can it know who you are and how (or if) it has served you in the past? The answer to that question involves using techniques to store information to help it remember who you are. That is what this article is all about. You can store this, "Hey Web server, remember me?" kind of information, on the client machine (client-based state management options), on the server (server-based state management options), or both.
The client-based techniques include ViewState, query strings, and cookies. The server-based techniques include application state, session state, and database support. I will first describe the client-side techniques and then I'll cover the server-based techniques.