We help IT Professionals succeed at work.

what are the differences between IsPostBack and ViewState?


I thought I understood the differeces between IsPostBack and ViewState. But, for some reason I am getting the two mix up. I understand that one will use IsPostBack when a page or object contains data and it is sent back to the server for a reload. The IsPostBack is supponsed to privent handler of code to not execute again if the page has been load once. Now, for the ViewState, what I think it does is to wrape an object on a hidden field an hashed it to maintain its information since HTTP is a stateless protocol.

Does the ViewState wrapes a single object or the entire page? Does the ViewState caches the data, therefore, improving pefomance? Is this caching perfored on the server side? What performance impacts are there on the server when IsPostBack or ViewState is used. Is there a time when to many objects, using ViewState, will dicrease the server performance?

Please, can some one explain in more depth the diffences between the IsPostBack and ViewState? When should one be used over the other? Can they be used together? I am not totally clear?
Watch Question


When Output cache is used in ASP.NET, does that cache works only for the user that have requested a particular information or every user will get the same output cache until that cache expires since this is done on the server side?
Plain and simple, IsPostBack is a boolean value which has its value set by whether or not the code being run is a result of a postback or not.  When you first navigate to a page, IsPostBack will be set to false.  When you do something on the page that causes a postback, such as clicking on a button, the postback occurs and IsPostBack is set to true.  As you said, this is used to decide whether or not certain code can be run.

Also, as you said, the ViewState is a hidden field on the page which contains a hashed representation of the current state of all objects on the page (provided ViewState is enabled for all controls).  When a page is first being requested, the values which are to be stored in the controls (text in textboxes/labels, items in listboxes, options in dropdowns, whether or not a checkbox or radiobutton is selected, etc) are all hashed and placed into viewstate.  When a user does a postback, the server needs some way of know what has been changed on the client-side.  Again, the current values/states of all controls are added into the ViewState in order for the server to know what happened.  Essentially you can think of it like an exchange of photographs.  Server writes a message into ViewState and says "here's what I look like, now you copy me.".  The user makes some changes and submits and the client says "ok, I looked like you, but now I look like this.  You copy me now.".  In this way the client and the server maintain their current state.
Oh and of course since this ViewState is being passed back and forth with every postback, it does incur a bit of extra cost since it has to send data back and forth, but in most cases this is vital.

There are some cases where you can turn off viewstate.  Basically you can turn off ViewState on anything that will automatically be altered/rebuilt on postback (such as a grid that's bound on postback or a label that's populated with text every time the page is rendered) AND cannot be altered by the client (in other words you don't care what changes the client makes to a control, if they even can make changes).

Also, ViewState is not technically caching, though it works a little bit like it on a page-by-page bases (once you leave a page, the viewstate that applied to that page is dumped).

As for your question regarding OutputCaching, it really depends on how you implement it.  You can specify whether to cache on the server or on the client (among other options).  I believe if you cache on the client, each user trying to access the page will get a fresh copy the first time they visit or after their current copy expires.
Guy Hengel [angelIII / a3]Billing Engineer
Most Valuable Expert 2014
Top Expert 2009

Bane83 is totally right, points to him.
just to make it 100% clear:
>When should one be used over the other? Can they be used together?
you do not use "either" of them. they HAVE to be used together...

Explore More ContentExplore courses, solutions, and other research materials related to this topic.