ASP.NET State Management
ASP.NET includes a variety of options for state management. It features the same Session and Application
state collections as traditional ASP (with a few enhancements) and an entirely new view state
model. ASP.NET even includes a caching system that allows you to retain information without sacrificing
server scalability. Each state management choice has a different lifetime, scope, performance
overhead, and level of support.
下表是Collection-based state.
|
|
Custom Cookies |
|
|
Caching |
Allowed Data Types |
All serializable .NET data types. |
String data. |
All serializable .net date types Nonserializable types are supported if you are using the default in-process state service |
All .NET data types |
All .NET data types |
Storage Location |
A hidden field in the current web page. |
The client’s computer (in memory or a small text file, depending on its lifetime settings). |
Server memory |
Server memory |
Server memory |
Lifetime |
Retained permanently for postbacks to a single page |
Set by the programmer. It can be used in multiple pages and can persist between visits. |
Times out after a predefined period(usually 20 minutes) |
The lifetime of the application |
Depends on the expiration policy you set but may possibly be released early if server memory becomes scarce. |
Scope |
Limited to the current Page |
The whole asp.net application |
The whole ASP.NET application |
The whole ASP.NET application .Unlike most other types of the methods .application data is global to all users |
The same as application state |
Security |
By default it’s insecure, although you can use Page directives to enforce encryption and hashing. |
Insecure and can be modified by the user |
Secure.because the data is never transmitted to the client.However, subject to session hijacking if you don not use SSL |
Very secure.because the data is never transmitted to the client. |
Very secure.because the data is never transmitted to the client. |
Performance Implications |
Storing a large amount of information will slow transmission but will not affect server performance |
None,because the amount f the data is trivial. |
Storing a large amount of information can slow down the server severely. Especially if there are a large number of user will have a separate copy of sessiondata. |
Storing a large amount of information can slow down the server severely. Because this data will never time out and be removed |
Storing a large amount of information may force out other , more useful cached information. However ,ASP.NET has the ability to remove items early to ensure optimum performance. |
Typical Use |
Page-specific settings |
Personalication preferences for website |
Store items in a shopping basket. |
Storing any types of global data |
Storing data retrieved from a databse |
|
Profiles |
Query String |
Allowed Data Types |
All serializable .NET data types Nonserializable types are supported if you create a custom profile. |
A limited amount of string data. |
Storage Location |
A back-end database. |
The browser’s URL string. |
Lifetime |
Permanent. |
Lost when the user enters a new URL or closes the browser. However, can be stored in a bookmark. |
Scope |
The whole ASP.NET application. |
Limited to the target page |
Security |
Fairly secure, because although stored in a database that could be compromised. |
Clearly visible and easy for the user to modify. |
Performance Implications |
Large amounts of data can be stored easily, but there may be a nontrivial overhead in retrieving and writing the data for each request. |
None, because the amount of data is trivial. |
Typical Use |
Store customer account information. |
Sending a product ID from a catalog page to a details page. |