| home / programming / asp / viewstate |    [previous] [next] |
|
|
This is the typical scenario of a Web site on the Internet, e.g. an e-commerce site. While it is easy to assign more hardware to alleviate performance issues, there is little that can be done about network bandwidth at the client side. Generally, pages should be made as light as possible. A highly interactive page with server side controls belonging to the heavy control group will add a lot of viewstate data, increasing the size of the page considerably. This viewstate not only needs to be downloaded by the client but also uploaded during post back. Thus, a 1 Kb increase in viewstate increases the traffic by 2 Kb.
Thus, our strategy’s main aim should be to minimize viewstate data.
The DataGrid control is a particularly heavy viewstate user. By default, all
of the data displayed in the grid is also stored in viewstate, and this is particularly
useful when an expensive operation (like a complex SQL query) is required to fetch the data.
However, this behavior also makes DataGrid the prime suspect for unnecessary
viewstate. If sorting and paging is being used then a rebind of the
DataGrid to its dataview class is necessary on every post back
and the entire viewstate of the DataGrid is unnecessary. Even
when sorting and paging is not being used the grid should be rebound on every post back.
If this rebinding requires a complex query then it is worthwhile to investigate whether
the query can be broken into expensive and not so expensive operations. If this can be
done then only the results of the expensive operations need be stored in the viewstate
and reused on every post back to rebind the grid.
Sometimes data can be added to the viewstate judiciously for overall benefit. The most striking example is provided by Web farms. Typically, in these scenarios the session state is persisted in an external database since a session may jump between servers during its lifetime. In this case, the session data is fetched from the database, deserialized and made available to the page. Any changes to the session data that follow are serialized and persisted to the database. Although ASP.NET's session persistence makes it easy to implement this, it is an expensive process. Instead, if this data is stored in viewstate then the roundtrip access to the database can be completely eliminated. While adding data to the viewstate, keep in mind that viewstate is optimized to work with the following types:
The above should allow the ability to store most data structures into viewstate. Once again, there is a critical amount of data when it becomes more efficient to store it in the database. This will depend on the individual characteristics of the application setup and can only be found empirically.
The are two caveats that should be kept in mind when persisting data in viewstate. First, viewstate data is easy to decode (since it is basically base64 coding). Thus, any sensitive information (e.g. credit card numbers) should not be stored in viewstate and sent over an insecure link. Sensitive information can be stored in the viewstate if it is encrypted and hashed as described later. Second, sessions, unlike viewstate, time out after a predetermined time. If timeout functionality is required then sessions must be used instead of viewstate to store data.
| home / programming / asp / viewstate | [previous] [next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: November 20, 2002
Revised: November 20, 2002
URL: http://webreference.com/programming/asp/viewstate/2.html
