Hey guys,
State management is something that I've just started to look into (thanks to some great dialogue with ja2000). ASP.NET offers quite a few ways, both on the server and client, to handle how your page keeps its state (look, values, etc.) between postbacks and refreshes. I found a great article on the vs.net's help library talking about it, and the post below covers the client side options youhave. I'll post another tip with the server ones, but if you do have vs.net, do a search in the index for ViewStateProperty, then select Saving Web Forms Page Values Using View State. one of the first links you'll see is to State Management Recommendations. That will bring you to the article. For all others, read on!
Jack
State management is the process by which you maintain state and page information over multiple requests for the same or different pages. As is true for any HTTP-based technology, Web Forms pages are stateless, which means that they do not automatically indicate whether the requests in a sequence are all from the same client or even whether a single browser instance is still actively viewing a page or site. Furthermore, pages are destroyed and recreated with each round trip to the server; therefore page information will not exist beyond the life cycle of a single page. For more information on server round trips and the Web Forms page life cycle, see Web Forms Page Processing.
ASP.NET provides multiple ways to maintain state between server round trips. Choosing among the options for state management available in ASP.NET will depend heavily upon your application, and it should be based on the following criteria:
How much information do you need to store?
Does the client accept persistent or in-memory cookies?
Do you want to store the information on the client or server?
Is the information sensitive?
What sorts of performance criteria do you have for your application?
ASP.NET supports various client-side and server-side options for state management.
Client-side options are:
The ViewState property
Hidden fields
Cookies
Query strings
Server-side options are:
Application state
Session state
Database
Client-Side State Management Options
Storing page information using client-side options doesn't use server resources. These options tend to have minimal security but fast server performance because the demand on server resources is modest. However, because you must send information to the client for it to be stored, there is a practical limit on how much information you can store this way.
View State
Web Forms pages provide the ViewState property as a built-in structure for automatically retaining values between multiple requests for the same page. View state is maintained as a hidden field in the page. For more information see Introduction to Web Forms State Management.
You can use view state to store your own page-specific values across round trips when the page posts back to itself. For example, if your application is maintaining user-specific information — that is, information used in the page but not necessarily part of any control — you can store it in view state.
The advantages of using view state are:
No server resources required. The view state is contained in a structure within the page code.
Simple implementation.
Automatic retention of page and control state.
Enhanced security features. The values in view state are hashed, compressed, and encoded for Unicode implementations, thus representing a higher state of security than hidden fields have.
The disadvantages of using the view state are:
Performance. Because the view state is stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.
Security. The view state is stored in a hidden field on the page. Although view state stores data in a hashed format, it can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information see Introduction to Web Application Security.
For more information on using view state, see Saving Web Forms Page Values Using View State.
Hidden Fields
You can store page-specific information in a hidden field on your page as a way of maintaining the state of your page. For more information on hidden fields see Introduction to Web Forms State Management.
If you use hidden fields, it is best to store only small amounts of frequently changed data on the client. ASP.NET provides the HtmlInputHidden control, which offers hidden field functionality. For more information on HtmlInputHidden see ASP.NET Server Controls by Function.
Note If you use hidden fields you must submit your pages to the server using the HTTP POST method rather than requesting the page via the page URL (the HTTP GET method).
The advantages of using hidden fields are:
No server resources are required. The hidden field is stored and read from the page.
Broad support. Almost all browsers and client devices support forms with hidden fields.
Simple implementation.
The disadvantages of using hidden fields are:
Security. The hidden field can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information see Introduction to Web Application Security.
Limited storage structure. The hidden field does not support rich structures. Hidden fields offer a single value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings.
Performance. Because hidden fields are stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.
Cookies
Cookies are useful for storing small amounts of frequently changed information on the client. The information is sent with the request to the server.
The advantages of using cookies are:
No server resources are required. The cookie is stored on the client and read by the server after a post.
Simplicity. The cookie is a lightweight, text-based structure with simple key-value pairs.
Configurable expiration. The cookie can expire when the browser session ends, or it can exist indefinitely on the client computer, subject to the expiration rules on the client.
The disadvantages of using cookies are:
Limited size. Most browsers place a 4096-byte limit on the size of a cookie, although the support for 8192-byte cookie size is becoming common in the new browser and client-device versions available today.
User-configured refusal. Some users disable their browser or client device's ability to receive cookies, thereby limiting this functionality.
Security. Cookies are subject to tampering. Users can manipulate cookies on their computer, which can potentially represent a security compromise or cause the application dependent on the cookie to fail. For more information see Introduction to Web Application Security.
Durability. The durability of the cookie on a client computer is subject to cookie expiration processes on the client and user intervention.
Note Cookies are often used for personalization, where content is customized for a known user. In most of these cases, identification is the issue rather than authentication, so it is enough to merely store the user name, account name, or a unique user ID (such as a GUID) in a cookie and use it to access the user personalization infrastructure of a site.
For details about creating and reading cookies, see HttpResponse.Cookies Property and HttpRequest.Cookies Property.
Query Strings
A query string is information appended to the end of a page's URL. For more information, see Introduction to Web Forms State Management.
You can use a query string to submit data back to your page or to another page through the URL. Query strings provide a simple but limited way of maintaining some state information. For example, they are an easy way to pass information from one page to another, such as passing a product number to another page where it will be processed.
Note Query strings are a viable option only when a page is requested via its URL. You cannot read a query string from a page that has been submitted to the server.
The advantages of using query strings are:
No server resources required. The query string is contained in the HTTP request for a specific URL.
Broad support. Almost all browsers and client devices support passing values in a query string.
Simple implementation. ASP.NET provides full support for the query string method, including methods of reading query strings using the HttpRequest.Params property.
The disadvantages of using query strings are:
Security. The information in the query string is directly visible to the user via the browser user interface. The query values are exposed to the Internet via the URL so in some cases security may be an issue. For more information on see Introduction to Web Application Security.
Limited capacity. Most browsers and client devices impose a 255-character limit on URL length.
State management is something that I've just started to look into (thanks to some great dialogue with ja2000). ASP.NET offers quite a few ways, both on the server and client, to handle how your page keeps its state (look, values, etc.) between postbacks and refreshes. I found a great article on the vs.net's help library talking about it, and the post below covers the client side options youhave. I'll post another tip with the server ones, but if you do have vs.net, do a search in the index for ViewStateProperty, then select Saving Web Forms Page Values Using View State. one of the first links you'll see is to State Management Recommendations. That will bring you to the article. For all others, read on!
Jack
State management is the process by which you maintain state and page information over multiple requests for the same or different pages. As is true for any HTTP-based technology, Web Forms pages are stateless, which means that they do not automatically indicate whether the requests in a sequence are all from the same client or even whether a single browser instance is still actively viewing a page or site. Furthermore, pages are destroyed and recreated with each round trip to the server; therefore page information will not exist beyond the life cycle of a single page. For more information on server round trips and the Web Forms page life cycle, see Web Forms Page Processing.
ASP.NET provides multiple ways to maintain state between server round trips. Choosing among the options for state management available in ASP.NET will depend heavily upon your application, and it should be based on the following criteria:
How much information do you need to store?
Does the client accept persistent or in-memory cookies?
Do you want to store the information on the client or server?
Is the information sensitive?
What sorts of performance criteria do you have for your application?
ASP.NET supports various client-side and server-side options for state management.
Client-side options are:
The ViewState property
Hidden fields
Cookies
Query strings
Server-side options are:
Application state
Session state
Database
Client-Side State Management Options
Storing page information using client-side options doesn't use server resources. These options tend to have minimal security but fast server performance because the demand on server resources is modest. However, because you must send information to the client for it to be stored, there is a practical limit on how much information you can store this way.
View State
Web Forms pages provide the ViewState property as a built-in structure for automatically retaining values between multiple requests for the same page. View state is maintained as a hidden field in the page. For more information see Introduction to Web Forms State Management.
You can use view state to store your own page-specific values across round trips when the page posts back to itself. For example, if your application is maintaining user-specific information — that is, information used in the page but not necessarily part of any control — you can store it in view state.
The advantages of using view state are:
No server resources required. The view state is contained in a structure within the page code.
Simple implementation.
Automatic retention of page and control state.
Enhanced security features. The values in view state are hashed, compressed, and encoded for Unicode implementations, thus representing a higher state of security than hidden fields have.
The disadvantages of using the view state are:
Performance. Because the view state is stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.
Security. The view state is stored in a hidden field on the page. Although view state stores data in a hashed format, it can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information see Introduction to Web Application Security.
For more information on using view state, see Saving Web Forms Page Values Using View State.
Hidden Fields
You can store page-specific information in a hidden field on your page as a way of maintaining the state of your page. For more information on hidden fields see Introduction to Web Forms State Management.
If you use hidden fields, it is best to store only small amounts of frequently changed data on the client. ASP.NET provides the HtmlInputHidden control, which offers hidden field functionality. For more information on HtmlInputHidden see ASP.NET Server Controls by Function.
Note If you use hidden fields you must submit your pages to the server using the HTTP POST method rather than requesting the page via the page URL (the HTTP GET method).
The advantages of using hidden fields are:
No server resources are required. The hidden field is stored and read from the page.
Broad support. Almost all browsers and client devices support forms with hidden fields.
Simple implementation.
The disadvantages of using hidden fields are:
Security. The hidden field can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information see Introduction to Web Application Security.
Limited storage structure. The hidden field does not support rich structures. Hidden fields offer a single value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings.
Performance. Because hidden fields are stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.
Cookies
Cookies are useful for storing small amounts of frequently changed information on the client. The information is sent with the request to the server.
The advantages of using cookies are:
No server resources are required. The cookie is stored on the client and read by the server after a post.
Simplicity. The cookie is a lightweight, text-based structure with simple key-value pairs.
Configurable expiration. The cookie can expire when the browser session ends, or it can exist indefinitely on the client computer, subject to the expiration rules on the client.
The disadvantages of using cookies are:
Limited size. Most browsers place a 4096-byte limit on the size of a cookie, although the support for 8192-byte cookie size is becoming common in the new browser and client-device versions available today.
User-configured refusal. Some users disable their browser or client device's ability to receive cookies, thereby limiting this functionality.
Security. Cookies are subject to tampering. Users can manipulate cookies on their computer, which can potentially represent a security compromise or cause the application dependent on the cookie to fail. For more information see Introduction to Web Application Security.
Durability. The durability of the cookie on a client computer is subject to cookie expiration processes on the client and user intervention.
Note Cookies are often used for personalization, where content is customized for a known user. In most of these cases, identification is the issue rather than authentication, so it is enough to merely store the user name, account name, or a unique user ID (such as a GUID) in a cookie and use it to access the user personalization infrastructure of a site.
For details about creating and reading cookies, see HttpResponse.Cookies Property and HttpRequest.Cookies Property.
Query Strings
A query string is information appended to the end of a page's URL. For more information, see Introduction to Web Forms State Management.
You can use a query string to submit data back to your page or to another page through the URL. Query strings provide a simple but limited way of maintaining some state information. For example, they are an easy way to pass information from one page to another, such as passing a product number to another page where it will be processed.
Note Query strings are a viable option only when a page is requested via its URL. You cannot read a query string from a page that has been submitted to the server.
The advantages of using query strings are:
No server resources required. The query string is contained in the HTTP request for a specific URL.
Broad support. Almost all browsers and client devices support passing values in a query string.
Simple implementation. ASP.NET provides full support for the query string method, including methods of reading query strings using the HttpRequest.Params property.
The disadvantages of using query strings are:
Security. The information in the query string is directly visible to the user via the browser user interface. The query values are exposed to the Internet via the URL so in some cases security may be an issue. For more information on see Introduction to Web Application Security.
Limited capacity. Most browsers and client devices impose a 255-character limit on URL length.