• No server resources are requiredВ В В The view state is contained in a structure within the page code.

• Simple implementationВ В В View state does not require any custom programming to use. It is on by default to maintain state data on controls.

• Enhanced security featuresВ В В The values in view state are hashed, compressed, and encoded for Unicode implementations, which provides more security than using hidden fields.

• Performance considerationsВ В В 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.

• Device limitationsВ В В Mobile devices might not have the memory capacity to store a large amount of view-state data.

• Potential security risksВ В В 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. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

For more information about using view state, see View State Overview.

• No server resources are requiredВ В В By default, control state is stored in hidden fields on the page.

• ReliabilityВ В В Because control state cannot be turned off like view state, control state is a more reliable method for managing the state of controls.

• VersatilityВ В В Custom adapters can be written to control how and where control-state data is stored.

• 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.

• No server resources are requiredВ В В The hidden field is stored and read from the page.

• Widespread supportВ В В Almost all browsers and client devices support forms with hidden fields.

• Simple implementationВ В В Hidden fields are standard HTML controls that require no complex programming logic.

• Potential security risksВ В В 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. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

• Simple storage architectureВ В В 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.

• Performance considerationsВ В В 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.

• Storage limitationsВ В В 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. If you need to store many items of data, consider doing one of the following:

  • Put each item in a separate hidden field.

  • Use view state with view-state chunking turned on, which automatically separates data into multiple hidden fields.

  • Instead of storing data on the client, persist the data on the server. The more data you send to the client, the slower the apparent response time of your application will be because the browser will need to download or send more data.

• Configurable expiration rulesВ В В 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.

• 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.

• Data persistenceВ В В 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.

• Size limitationsВ В В 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.

• User-configured refusalВ В В Some users disable their browser or client device's ability to receive cookies, thereby limiting this functionality.

• Potential security risksВ В В Cookies are subject to tampering. 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. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

  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. Thus, you can typically secure a cookie that is used for identification by storing the user name, account name, or a unique user ID (such as a GUID) in the cookie and then using the cookie to access the user personalization infrastructure of a site.

• No server resources are requiredВ В В The query string is contained in the HTTP request for a specific URL.

• Widespread supportВ В В Almost all browsers and client devices support using query strings to pass values.

• Simple implementationВ В В ASP.NET provides full support for the query-string method, including methods of reading query strings using the Params property of the HttpRequest object.

• Potential security risksВ В В 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. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.

• Limited capacityВ В В Some browsers and client devices impose a 2083-character limit on the length of URLs.

• Simple implementationВ В В Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.

• Application scopeВ В В 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 (for instance, as opposed to keeping copies of information in session state or in individual pages).

• Application scopeВ В В 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.

• Limited durability of dataВ В В 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.

• Resource requirementsВ В В Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.

Careful design and implementation of application state can increase Web application performance. For example, placing a commonly used, relatively static dataset in application state can increase site performance by reducing the overall number of data requests to a database. However, there is a performance trade-off. Application state variables containing large blocks of information reduce Web server performance as server load increases. The memory occupied by a variable stored in application state is not released until the value is either removed or replaced. Therefore, it is best to use application-state variables only with small, infrequently changed datasets. For more information, see Developing High-Performance ASP.NET Applications.

• Simple implementationВ В В The session-state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.

• Session-specific eventsВ В В Session management events can be raised and used by your application.

• Data persistenceВ В В 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.

• Platform scalabilityВ В В Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.

• Cookieless supportВ В В 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. For more information about using session state without cookies, see Configuring ASP.NET Applications.

• ExtensibilityВ В В 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. For more information, see Implementing a Session-State Store Provider.

• 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.

• Data persistenceВ В В 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.

• Platform scalabilityВ В В Profile properties can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.

• ExtensibilityВ В В 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. For more information, see ASP.NET Profile Providers and Implementing a Profile Provider.

• Performance considerationsВ В В Profile properties are generally slower than using session state because instead of storing data in memory, the data is persisted to a data store.

• Additional configuration requirementsВ В В 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. For more information, see ASP.NET Profile Properties Overview and Defining ASP.NET Profile Properties.

• Data maintenanceВ В В 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.

• SecurityВ В В Access to databases requires rigorous authentication and authorization.

• Storage capacityВ В В You can store as much information as you like in a database.

• Data persistenceВ В В Database information can be stored as long as you like, and it is not subject to the availability of the Web server.

• Robustness and data integrityВ В В Databases include various facilities for maintaining good data, including triggers and referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.

• AccessibilityВ В В The data stored in your database is accessible to a wide variety of information-processing tools.

• Widespread supportВ В В There is a large range of database tools available, and many custom configurations are available.

• ComplexityВ В В Using a database to support state management requires that the hardware and software configurations be more complex.

• Performance considerationsВ В В Poor construction of the relational data model can lead to scalability issues. Also, leveraging too many queries to the database can adversely affect server performance.