Administrator
VB.NET Forum Admin
- Joined
- Jun 3, 2004
- Messages
- 1,462
- Programming Experience
- 10+
In reviewing an e-commerce application (BV Commerce 2004) I'd like to share my opinion on the use of, or misuse in this case, viewstate.
As many know, viewstate is a "storage" mechanism for persisting information, typically designed for preserving values during a postback for server controls such as textboxes, etc. Viewstate is a nice feature, but if not used properly, can significantly impact performance of any asp.net web site.
In the scenario of this e-commerce application I reviewed viewstate is being used to store far more then just page level server controls and in doing this, you are asking "the client" to carry the burden of your programming. Realize that the more you "grow" viewstate, the larger the pages become and the client has to pass this back and forth to the server, and we all know not everyone has a 100 mbit connection to the world!
There are alternatives, such as "server side" viewstate which is actually covered in this months asp.NET PRO magazine, session variables, shared variables, and many other options that are far more effective then asking your web surfers/visitors to be carrying your load.
So those designing effectively with performance in mind, taking advantage of the increased performance of ASP.NET need to look really hard at the use, or abuse in this case, of viewstate. Viewstate can be your friend, but rapidly grow to be your enemy. Those using Datagrids know viewstate can get ugly fast, look at the server side viewstate storage options using the Page Overloads of:
LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium
Although again this is not recommended for high activity web sites as you are now putting the load on the server, you have to decide again WHAT you are going to use Viewstate for and keep it to a bare minimum.
Bottom line: Design for performance, don't penalize your web visitors and make them carry the burden of your programming!
As many know, viewstate is a "storage" mechanism for persisting information, typically designed for preserving values during a postback for server controls such as textboxes, etc. Viewstate is a nice feature, but if not used properly, can significantly impact performance of any asp.net web site.
In the scenario of this e-commerce application I reviewed viewstate is being used to store far more then just page level server controls and in doing this, you are asking "the client" to carry the burden of your programming. Realize that the more you "grow" viewstate, the larger the pages become and the client has to pass this back and forth to the server, and we all know not everyone has a 100 mbit connection to the world!
There are alternatives, such as "server side" viewstate which is actually covered in this months asp.NET PRO magazine, session variables, shared variables, and many other options that are far more effective then asking your web surfers/visitors to be carrying your load.
So those designing effectively with performance in mind, taking advantage of the increased performance of ASP.NET need to look really hard at the use, or abuse in this case, of viewstate. Viewstate can be your friend, but rapidly grow to be your enemy. Those using Datagrids know viewstate can get ugly fast, look at the server side viewstate storage options using the Page Overloads of:
LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium
Although again this is not recommended for high activity web sites as you are now putting the load on the server, you have to decide again WHAT you are going to use Viewstate for and keep it to a bare minimum.
Bottom line: Design for performance, don't penalize your web visitors and make them carry the burden of your programming!
