Choosing the Right ASP.NET State Management Option


State management is a vastly more complicated topic in ASP.NET than it is in classic ASP. The choices you need to make are not as clear-cut as before because you now have different options for accomplishing the same task. ASP.NET does allow you to manage state in the most optimal way for your Web application. The burden is on you, the developer, to make the right choices on which approach you need to take.

When considering using session state, ask the following questions:

  • Does the application require centralized session state management, or can it be managed on individual Web servers? ASP.NET provides StateServer and SQLServer modes for centralized session state. ASP.NET provides InProc, StateServer, and SQLServer modes for server-specific session state.

  • Does the application require cookie-based or cookieless session state? Most Web clients support cookies, so cookie-based session state is a good approach for the vast majority of Web clients . Cookieless session state requires the application to contain relative links only. Also, the application is more vulnerable to losing a session reference because the ID is stored in plain text in the URL, which can be easily tampered with.

  • What kind of information needs to be stored? The InProc session state mode stores any data type, although you should be careful not to store objects that could present threading issues. The StateServer and SQLServer session state modes can only store objects that support binary serialization. This includes most of the simple data types (string, integer, Boolean) as well as some specialized objects, including the DataSet object.

  • Does the application really need a Session object for all information? Session state management is typically more expensive than application state management because the server provides every client with its own copy of the same information. You should only store information in session state that is truly specific to an individual client. Technically, the ap_SalesQueryWithSession.aspx page presented earlier is not a good use of session state and would be better suited for caching. This is because the DataSet contents vary by request parameters, not by individual client.

When considering using application state, ask the following questions:

  • Does the application require permanent application state? Permanent state values are guaranteed to be available as long as the ASP.NET application remains loaded. You can store permanent state values in the Web.config file. This file is suitable for storing configuration values, but it cannot be used to store objects. Permanent state values may also be stored in the HttpApplicationState class, but then they must be compiled with the application, and there is nothing to prevent them from being modified at runtime. Alternatively, you can set up a public shared variable in the Global.asax file and initialize it with a reference value or object. This variable is accessible throughout the application; however, it does not provide concurrency management. You should not set shared variables more than once, and they should be primarily read-only for the application to prevent concurrency problems. Often these variables are set once ( initialized ) in the Global.asax file and then are treated as read-only throughout the rest of the application.

  • Does the application require transient application state? The HttpApplicationState class (the Application object) stores a wide range of objects and data types in memory, and it will persist them until a user alters them or until the application unloads. The Cache class provides more granular control over application data, but it does not guarantee that items will remain persistent in memory. Application code that references cached items must have a contingency for re-creating an item that cannot be retrieved from the cache. The Application object avoids this inconvenience, but it provides none of the storage efficiencies of the Cache class.

  • How frequently will stored items be updated? You should store reference values used throughout an application in the Web.config file because ASP.NET will automatically reload the application when this file changes. You must store reference objects used throughout an application in the Application object. If one or more of these references changes, then you must recompile the application. Alternatively, you can store object references in the Cache class using dependency expiration. For example, a DataSet may be added to the cache, and the cached reference will be used throughout the application as long as its dependency resource remains unchanged.

  • Does the client need direct access to the item? If the client does not require direct access to an application item, then consider creating a custom base class for the Global.asax file and storing the item using a class property. For example, you can store a request counter in a class property and automatically increment in it the Global.asax Application_BeginRequest() method.

Ultimately, your choice for managing state comes down to the type of item, how it gets accessed, and whether the item must remain persistent or can be recreated. If used correctly, state management is an important factor in developing optimal ASP.NET applications.




Performance Tuning and Optimizing ASP. NET Applications
Performance Tuning and Optimizing ASP.NET Applications
ISBN: 1590590724
EAN: 2147483647
Year: 2005
Pages: 91

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net