Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Review
Because of the statelessness of HTTP, there is no de facto standard technique that Web applications use to store user state information. Five common techniques have been presented in this paper, and their advantages and disadvantages are summarized on Table 1. ASP Sessions usually require the least amount of coding, but require the use of cookies and suffer from scalability problems. Therefore, if you want to make sure that your Web applications work for all users and are scalable, take some time up-front to develop a reusable technique for maintaining user state information on the server. I suggest generating a unique identifier for each user, passing it back and forth between the client and server in the URL query string, and storing state information on the server in a database table or simple file. In my follow-up article, I'll demonstrate how this might be implemented.
Table 1 Comparison of State Retention Techniques
|
|
Client Techniques |
Server Techniques |
|||
|
Cookies |
Hidden HTML Form Fields |
Query Strings |
ASP Sessions |
Roll Your Own |
|
|
Advantages |
|||||
|
Relatively easy to code |
x |
|
|
x |
x |
|
Can store complex data types (that is, COM objects) |
|
|
|
x |
|
|
Works well in load balancing environments |
x |
x |
x |
|
x |
|
Disadvantages |
|||||
|
User can tamper with state information |
x |
x |
x |
|
|
|
Requires cookies |
x |
|
|
x |
|
|
Requires minimal coding |
x |
|
|
x |
|
|
Can store only small amount of data (~2,000 bytes) |
|
|
x |
|
|
|
Increased network traffic and slightly slower response times |
x |
x |
x |
|
|
|
Requires server resources to save state information |
|
|
|
x |
x |
|
Application logic tightly coupled to the user interface implementation |
|
x |
|
|
|