State management
ASP.NET applications are hosted by a web server and are accessed using the stateless HTTP protocol. As such, if an application uses stateful interaction, it has to implement state management on its own. ASP.NET provides various functions for state management. Conceptually, Microsoft treats "state" as GUI state. Problems may arise if an application needs to keep track of "data state"; for example, a finite state machine which may be in a transient state between requests (lazy evaluation) or which takes a long time to initialize. State management in ASP.NET pages with authentication can make Web scraping difficult or impossible.Application State
Application state is held by a collection of shared user-defined variables. These are set and initialized when the Application_OnStart
event fires on the loading of the first instance of the application and are available until the last instance exits. Application state variables are accessed using the Applications
collection, which provides a wrapper for the application state variables. Application state variables are identified by name.Session state
Server-side session state is held by a collection of user-defined session variables that are persistent during a user session. These variables, accessed using theSession
collection, are unique to each session instance. The variables can be set to be automatically destroyed after a defined time of inactivity even if the session does not end. Client-side user session is maintained by either a cookie or by encoding the session ID in the URL itself.ASP.NET supports three modes of persistence for server-side session variables:
- In-Process Mode
- The session variables are maintained within the ASP.NET process. This is the fastest way; however, in this mode the variables are destroyed when the ASP.NET process is recycled or shut down.
- ASPState Mode
- ASP.NET runs a separate Windows service that maintains the state variables. Because state management happens outside the ASP.NET process, and because the ASP.NET engine accesses data using .NET Remoting, ASPState is slower than In-Process. This mode allows an ASP.NET application to be load-balanced and scaled across multiple servers. Because the state management service runs independently of ASP.NET, the session variables can persist across ASP.NET process shutdowns. However, since session state server runs as one instance, it is still one point of failure for session state. The session-state service cannot be load-balanced, and there are restrictions on types that can be stored in a session variable.
- SqlServer Mode
- State variables are stored in a database, allowing session variables to be persisted across ASP.NET process shutdowns. The main advantage of this mode is that it allows the application to balance load on a server cluster, sharing sessions between servers. This is the slowest method of session state management in ASP.NET.
View state
View state refers to the page-level state management mechanism, utilized by the HTML pages emitted by ASP.NET applications to maintain the state of the web form controls and widgets. The state of the controls is encoded and sent to the server at every form submission in a hidden field known as__VIEWSTATE
. The server sends back the variable so that when the page is re-rendered, the controls render at their last state. At the server side, the application may change the viewstate, if the processing requires a change of state of any control. The states of individual controls are decoded at the server, and are available for use in ASP.NET pages using the ViewState
collection.The main use for this is to preserve form information across postbacks. View state is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a postback. This behavior can (and should) be modified, however, as View state can be disabled on a per-control, per-page, or server-wide basis.
Developers need to be wary of storing sensitive or private information in the View state of a page or control, as the base64 string containing the view state data can easily be de-serialized. By default, View state does not encrypt the
__VIEWSTATE
value. Encryption can be enabled on a server-wide (and server-specific) basis, allowing for a certain level of security to be maintained.
No comments:
Post a Comment