State Management Advantages and Disadvantages
State management is the process by which you maintain state and page information over multiple requests for the same or different pages.
client-side state management
View state
Control state
Hidden fields
Cookies
Query strings
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
Advantages of using view state:
The view state is contained in a structure within the page code.
View state does not require any custom programming to use. It is on by default to maintain state data on controls.
The values in view state are hashed, compressed, and encoded for Unicode implementations, which provides more security than using hidden fields.
Disadvantages of using view state:
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. This is especially relevant for mobile devices, where bandwidth is often a limitation.
Mobile devices might not have the memory capacity to store a large amount of view-state data.
The view state is stored in one or more hidden fields on the page. Although view state stores data in a hashed format, it can still 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
Control State
The ASP.NET page framework provides the ControlState property as way to store custom control data between server trips
Advantages of using control state are:
By default, control state is stored in hidden fields on the page.
Because control state cannot be turned off like view state, control state is a more reliable method for managing the state of controls.
Custom adapters can be written to control how and where control-state data is stored.
Disadvantage of using control state are:
Some programming is required While the ASP.NET page framework provides a foundation for control state, control state is a custom state-persistence mechanism. To fully utilize control state, you must write code to save and load control 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.If you use hidden fields, it is best to store only small amounts of frequently changed data on the client.
Advantages of using hidden fields are:
The hidden field is stored and read from the page.
Almost all browsers and client devices support forms with hidden fields.
Hidden fields are standard HTML controls that require no complex programming logic.
Disadvantages of using hidden fields are:
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. You can manually encrypt and decrypt the contents of a hidden field, but doing so requires extra coding and overhead. If security is a concern, consider using a server-based state mechanism so that no sensitive information is sent to the client.
The hidden field does not support rich data types. Hidden fields offer a single string value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings. You can manually serialize and de-serialize rich data types to and from hidden fields, respectively. However, it requires extra code to do so. If you need to store rich data types on the client, consider using view state instead. View state has serialization built-in, and it stores data in hidden fields.
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.
If the amount of data in a hidden field becomes very large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum amount can vary with different firewall and proxy implementations, large hidden fields can be sporadically problematic
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
Advantages of using cookies are:
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 cookie is stored on the client and read by the server after a post.
The cookie is a lightweight, text-based structure with simple key-value pairs.
Although the durability of the cookie on a client computer is subject to cookie expiration processes on the client and user intervention, cookies are generally the most durable form of data persistence on the client.
Disadvantages of using cookies are:
Most browsers place a 4096-byte limit on the size of a cookie, although support for 8192-byte cookies is becoming more common in newer browser and client-device versions.
Some users disable their browser or client device's ability to receive cookies, thereby limiting this functionality.
Users can manipulate cookies on their computer, which can potentially cause a security risk or cause the application that is dependent on the cookie to fail. Also, although cookies are only accessible by the domain that sent them to the client, hackers have historically found ways to access cookies from other domains on a user's computer. You can manually encrypt and decrypt cookies, but it requires extra coding and can affect application performance because of the time that is required for encryption and decryption
Query Strings
A query string is information that is appended to the end of a page URL.
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, query strings 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.
Advantages of using query strings are:
The query string is contained in the HTTP request for a specific URL.
Almost all browsers and client devices support using query strings to pass values.
ASP.NET provides full support for the query-string method, including methods of reading query strings using the Params property of the HttpRequest object.
Disadvantages of using query strings are:
The information in the query string is directly visible to the user via the browser's user interface. A user can bookmark the URL or send the URL to other users, thereby passing the information in the query string along with it. If you are concerned about any sensitive data in the query string, consider using hidden fields in a form that uses POST instead of using query strings
Some browsers and client devices impose a 2083-character limit on the length of URLs.
Server-Side State Management Options
Server-side options for storing page information typically have higher security than client-side options, but they can use more Web server resources, which can lead to scalability issues when the size of the information store is large.
server-side state management options that ASP.NET supports:
Application state
Session state
Profile properties
Database support
Application State
ASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific information that is visible to the entire application. Application-state variables are, in effect, global variables for an ASP.NET application
Advantages of using application state are:
Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Because application state is accessible to all pages in an application, storing information in application state can mean keeping only a single copy of the information.
Disadvantages of using application state are:
The scope of application state can also be a disadvantage. Variables stored in application state are global only to the particular process the application is running in, and each application process can have different values. Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-farm server configurations.
Because global data that is stored in application state is volatile, it will be lost if the Web server process containing it is destroyed, such as from a server crash, upgrade, or shutdown.
Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.
Session State
ASP.NET provides a session state, which is available as the HttpSessionState class, as a method of storing session-specific information that is visible only within the session. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides the ability to persist variable values for the duration of that session.
Advantages of using session state are:
The session-state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Session management events can be raised and used by your application.
Data placed in session-state variables can be preserved through Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space. Additionally, session-state data can be persisted across multiple processes, such as in a Web farm or a Web garden.
Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. Using session state without cookies, however, requires that the session identifier be placed in the query string, which is subject to the security issues stated in the query string section of this topic.
You can customize and extend session state by writing your own session-state provider. Session state data can then be stored in a custom data format in a variety of data storage mechanisms, such as a database, an XML file, or even to a Web service.
Disadvantage of using session state are:
Performance considerations Session-state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session-state variables that contain blocks of information, such as large datasets, can adversely affect Web-server performance as server load increases.
Profile Properties
ASP.NET provides a feature called profile properties, which allows you to store user-specific data. It is similar to session state, except that unlike session state, the profile data is not lost when a user's session expires. The profile properties feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user.
The ASP.NET profile allows you to easily manage user information without requiring you to create and maintain your own database. In addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in your application. You can store objects of any type in the profile.
The ASP.NET profile feature provides a generic storage system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner
Advantages of using profile properties are:
Data placed in profile properties is preserved through IIS restarts and worker-process restarts without losing data because the data is stored in an external mechanism. Additionally, profile properties can be persisted across multiple processes, such as in a Web farm or a Web garden.
Profile properties can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
In order to use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a custom format and to a custom storage mechanism, such as an XML file, or even to a Web service.
Disadvantages of using profile properties are:
Profile properties are generally slower than using session state because instead of storing data in memory, the data is persisted to a data store.
Unlike session state, the profile properties feature requires a considerable amount of configuration to use. To use profile properties, you must not only configure a profile provider, but you must pre-configure all of the profile properties that you want to store.
Profile properties require a certain amount of maintenance. Because profile data is persisted to non-volatile storage, you must make sure that your application calls the appropriate cleanup mechanisms, which are provided by the profile provider, when data becomes stale.
State management is the process by which you maintain state and page information over multiple requests for the same or different pages.
client-side state management
View state
Control state
Hidden fields
Cookies
Query strings
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
Advantages of using view state:
The view state is contained in a structure within the page code.
View state does not require any custom programming to use. It is on by default to maintain state data on controls.
The values in view state are hashed, compressed, and encoded for Unicode implementations, which provides more security than using hidden fields.
Disadvantages of using view state:
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. This is especially relevant for mobile devices, where bandwidth is often a limitation.
Mobile devices might not have the memory capacity to store a large amount of view-state data.
The view state is stored in one or more hidden fields on the page. Although view state stores data in a hashed format, it can still 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
Control State
The ASP.NET page framework provides the ControlState property as way to store custom control data between server trips
Advantages of using control state are:
By default, control state is stored in hidden fields on the page.
Because control state cannot be turned off like view state, control state is a more reliable method for managing the state of controls.
Custom adapters can be written to control how and where control-state data is stored.
Disadvantage of using control state are:
Some programming is required While the ASP.NET page framework provides a foundation for control state, control state is a custom state-persistence mechanism. To fully utilize control state, you must write code to save and load control 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.If you use hidden fields, it is best to store only small amounts of frequently changed data on the client.
Advantages of using hidden fields are:
The hidden field is stored and read from the page.
Almost all browsers and client devices support forms with hidden fields.
Hidden fields are standard HTML controls that require no complex programming logic.
Disadvantages of using hidden fields are:
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. You can manually encrypt and decrypt the contents of a hidden field, but doing so requires extra coding and overhead. If security is a concern, consider using a server-based state mechanism so that no sensitive information is sent to the client.
The hidden field does not support rich data types. Hidden fields offer a single string value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings. You can manually serialize and de-serialize rich data types to and from hidden fields, respectively. However, it requires extra code to do so. If you need to store rich data types on the client, consider using view state instead. View state has serialization built-in, and it stores data in hidden fields.
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.
If the amount of data in a hidden field becomes very large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum amount can vary with different firewall and proxy implementations, large hidden fields can be sporadically problematic
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
Advantages of using cookies are:
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 cookie is stored on the client and read by the server after a post.
The cookie is a lightweight, text-based structure with simple key-value pairs.
Although the durability of the cookie on a client computer is subject to cookie expiration processes on the client and user intervention, cookies are generally the most durable form of data persistence on the client.
Disadvantages of using cookies are:
Most browsers place a 4096-byte limit on the size of a cookie, although support for 8192-byte cookies is becoming more common in newer browser and client-device versions.
Some users disable their browser or client device's ability to receive cookies, thereby limiting this functionality.
Users can manipulate cookies on their computer, which can potentially cause a security risk or cause the application that is dependent on the cookie to fail. Also, although cookies are only accessible by the domain that sent them to the client, hackers have historically found ways to access cookies from other domains on a user's computer. You can manually encrypt and decrypt cookies, but it requires extra coding and can affect application performance because of the time that is required for encryption and decryption
Query Strings
A query string is information that is appended to the end of a page URL.
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, query strings 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.
Advantages of using query strings are:
The query string is contained in the HTTP request for a specific URL.
Almost all browsers and client devices support using query strings to pass values.
ASP.NET provides full support for the query-string method, including methods of reading query strings using the Params property of the HttpRequest object.
Disadvantages of using query strings are:
The information in the query string is directly visible to the user via the browser's user interface. A user can bookmark the URL or send the URL to other users, thereby passing the information in the query string along with it. If you are concerned about any sensitive data in the query string, consider using hidden fields in a form that uses POST instead of using query strings
Some browsers and client devices impose a 2083-character limit on the length of URLs.
Server-Side State Management Options
Server-side options for storing page information typically have higher security than client-side options, but they can use more Web server resources, which can lead to scalability issues when the size of the information store is large.
server-side state management options that ASP.NET supports:
Application state
Session state
Profile properties
Database support
Application State
ASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific information that is visible to the entire application. Application-state variables are, in effect, global variables for an ASP.NET application
Advantages of using application state are:
Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Because application state is accessible to all pages in an application, storing information in application state can mean keeping only a single copy of the information.
Disadvantages of using application state are:
The scope of application state can also be a disadvantage. Variables stored in application state are global only to the particular process the application is running in, and each application process can have different values. Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-farm server configurations.
Because global data that is stored in application state is volatile, it will be lost if the Web server process containing it is destroyed, such as from a server crash, upgrade, or shutdown.
Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.
Session State
ASP.NET provides a session state, which is available as the HttpSessionState class, as a method of storing session-specific information that is visible only within the session. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides the ability to persist variable values for the duration of that session.
Advantages of using session state are:
The session-state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Session management events can be raised and used by your application.
Data placed in session-state variables can be preserved through Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space. Additionally, session-state data can be persisted across multiple processes, such as in a Web farm or a Web garden.
Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. Using session state without cookies, however, requires that the session identifier be placed in the query string, which is subject to the security issues stated in the query string section of this topic.
You can customize and extend session state by writing your own session-state provider. Session state data can then be stored in a custom data format in a variety of data storage mechanisms, such as a database, an XML file, or even to a Web service.
Disadvantage of using session state are:
Performance considerations Session-state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session-state variables that contain blocks of information, such as large datasets, can adversely affect Web-server performance as server load increases.
Profile Properties
ASP.NET provides a feature called profile properties, which allows you to store user-specific data. It is similar to session state, except that unlike session state, the profile data is not lost when a user's session expires. The profile properties feature uses an ASP.NET profile, which is stored in a persistent format and associated with an individual user.
The ASP.NET profile allows you to easily manage user information without requiring you to create and maintain your own database. In addition, the profile makes the user information available using a strongly typed API that you can access from anywhere in your application. You can store objects of any type in the profile.
The ASP.NET profile feature provides a generic storage system that allows you to define and maintain almost any kind of data while still making the data available in a type-safe manner
Advantages of using profile properties are:
Data placed in profile properties is preserved through IIS restarts and worker-process restarts without losing data because the data is stored in an external mechanism. Additionally, profile properties can be persisted across multiple processes, such as in a Web farm or a Web garden.
Profile properties can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
In order to use profile properties, you must configure a profile provider. ASP.NET includes a SqlProfileProvider class that allows you to store profile data in a SQL database, but you can also create your own profile provider class that stores profile data in a custom format and to a custom storage mechanism, such as an XML file, or even to a Web service.
Disadvantages of using profile properties are:
Profile properties are generally slower than using session state because instead of storing data in memory, the data is persisted to a data store.
Unlike session state, the profile properties feature requires a considerable amount of configuration to use. To use profile properties, you must not only configure a profile provider, but you must pre-configure all of the profile properties that you want to store.
Profile properties require a certain amount of maintenance. Because profile data is persisted to non-volatile storage, you must make sure that your application calls the appropriate cleanup mechanisms, which are provided by the profile provider, when data becomes stale.
