Wednesday, 7 September 2011

State Management

Introduction to State Management

State Management is process of saving information between page requests and postbacks on the server.

To make the communication between web server and web client meaningful and coherent, the state need to be saved between requests. All web applications function by using the Request/Response communication pattern. That means that for every request that comes from the client, the server will reply back with one response. In a stateless world, the server is just serving the reply back, but doesn’t remember what was said earlier in the communication.


Options for State Management

The state can be saved either on the server, or on the client. Both have advantages and disadvantages.

Server side

The data is saved where it is needed, but if there are too many clients simultaneously, the performance might be affected, and the resource usage will be high. Another thing that needs to be taken into consideration is scalability. If the data is saved locally on the server, then it will be difficult to make it work in a web farm scenario.
  • Application state: A key-value dictionary of objects that you can use to store data available to all the requests.
  • Session state: A key-value dictionary of objects that you can use to store data coming from a single client browser across multiple requests.
  • User profile: Allows you to define and store per-user settings to be used throughout your application.
  • Caching: Keys paired with values, where you can place items and later retrieve them.

Client side

The data is saved where it belongs, together with the page, but this creates unnecessary data transfers between the client and the server.
  • View state: The state of the page is serialized into XML, encoded Base64, and is then sent to the client as a hidden field.
  • Control state: Some controls are dependent on view state , but view state can be turned off, unlike control state, which cannot be turned off.
  • Posted data: State data is sent as hidden field, much the same as view state, but is not using XML serialization, or Base64 encoding.
  • Cookies: State data is sent as text as part of the HTTP header, in both the request and in the reply.
  • Query: State data is encoded in the query string, but this has the limitation of max 255 characters.


Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home