What are State Management techniques used in ASP.net?

State Management techniques used in ASP.NET can be categorized in two types:

1. Client-Side State Management
   • View State
   • Control State
   • Hidden Fields
   • Cookies
   • Query String
2. Server-Side State Management
   • Application State
   • Session State
   • Profile Properties
   • Cache

View State:

• ViewState is one of the Client-Side State Management techniques that provides page-level state management, which means state is preserved between subsequent requests to same page.
• By using this technique, state of the page along with its controls is stored in a hidden form field  i.e. “__VIEWSTATE” and this field is again available on server when page is posted back with HTTP Request.
• ViewState data is encoded in Base64 String encoded format.
• ViewState can be enabled or disable at different levels:
  • Control Level
    • ViewState for a specific control can be enabled or disabled by setting EnableViewState
  • Page Level
    • ViewState for a specific control can be enabled or disabled by setting EnableViewState
  • Application Level
    For whole application, we can enable/disable views in configuration file.

Control State:

• Use control state only for small amounts of critical data that are essential for the control across postbacks.
• Do not use control state as an alternative to view state

Hidden Field:

• The HiddenField control provides you a way to store information in the page without displaying it.
• For example, you might store a user-preference setting in a HiddenField control so that it can be read in client script.
• To put information into a HiddenField control, you set its Value property to the value you want to store between postbacks
• Store data in a hidden field on a page.
• Detect when data stored in the hidden field has changed between postbacks.

Cookies:

• A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser.
• The cookie contains information the Web application can read whenever the user visits the site.
• Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site
• Cookies are used for many purposes, all relating to helping the Web site remember users
• Cookies help Web sites store information about visitors
• A cookie limitation that you might encounter is that users can set their browser to refuse cookies

Query String:

• The QueryString collection retrieves the values of the variables in the HTTP query string.
• The HTTP query string is specified by the values following the question mark (?).
• Several different processes can generate a query string
• Query strings are also generated by sending a form or by a user typing a query into the address box of the browser
• Query strings are contained in request headers

Application State:

• Application state is basically a common data repository for an application’s all users and their all sessions
• Application state is stored in memory on the server and is faster than storing and retrieving information in a database
• You can use application state in two ways. You can add, access, or remove values from the contents collection directly through code.
• The HTTPApplicationState class can be accessed at any time during the life of an application

Application State Considerations:

• Resources: 
  • It is stored in memory, application state is very fast compared to saving data to disk or a database.
  • Storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk.
  • Alternatively, you can use the ASP.NET cache mechanism for storing large amounts of application data.
  • The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively manages the cache and will remove items when memory becomes scarce.
• Volatility:
  • Application state is stored in server memory, it is lost whenever the application is stopped or restarted.
  • For example, if the Web.config file is changed, the application is restarted and all application state is lost unless application state values have been written to a non-volatile storage medium such as a database.
• Scalability :
  • Application state is not shared among multiple servers serving the same application, as in a Web farm, or among multiple worker processes serving the same application on the same server, as in a Web garden. Your application therefore cannot rely on application state containing the same data for application state across different servers or processes.
  • If your application will run in multi-processor or multi-server environments, consider using a more scalable option, such as a database, for data that must preserve fidelity across the application.
• Concurrency:
  •    Application state is free-threaded, which means that application state data can be accessed simultaneously by many threads. Therefore, it is important to ensure that when you update application state data, you do so in a thread-safe manner by including built-in synchronization support.
  • You can use the Lock and UnLock methods to ensure data integrity by locking the data for writing by only one source at a time.
  • You can also reduce the likelihood of concurrency problems by initializing application state values in the Application_Start method in the Global.asax file.

Session State:

• Session state is specific to a single user session
• ASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web application
• Sessions are identified by a unique identifier that can be read by using the SessionID property.
• When session state is enabled for an ASP.NET application, each request for a page in the application is examined for a SessionID value sent from the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response.
• By default, SessionID values are stored in a cookie. However, you can also configure the application to store SessionID values in the URL for a “cookieless” session.
• A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired. Requests made with an expired SessionID value result in a new session

Profile Properties:

• The ASP.NET profile feature associates information with an individual user and stores the information in a persistent format.
• Profiles allow you to manage user information without requiring you to create and maintain your own database
• The ASP.NET profile feature makes the user information available using a strongly typed API that you can access from anywhere in your application.
• To use profiles, you first enable profiles by modifying the configuration file for your ASP.NET Web application

Cache:

• ASP.NET provides two types of caching that you can use to create high-performance Web applications.
• The first is output caching, which allows you to store dynamic page and user control responses on any HTTP 1.1 cache-capable device in the output stream, from the originating server to the requesting browser. On subsequent requests, the page or user control code is not executed; the cached output is used to satisfy the request.
• The second type of caching is application data caching, which you can use to programmatically store arbitrary objects, such as application data, in server memory so that your application can save the time and resources it takes to recreate them