I am quite new to WebForms and I’m trying to understand the ViewState. AFAIK today, it keeps modifications of the UI over postbacks to the same page. But why does it send the state (= stored modifications) to the client and does not keep it on the server saving CPU cycles and bandwidth?
Am I understanding something completely wrong?
The view state is something intrinsically connected to the view, as the name implies, and trying to manage it separately while maintaining that relation is not something that is easily accomplished.
You would need to store view state per page, so you would still have to send to the client an ID in order to be able to get the correct view state on a postback. Another serious issue is that you send a page to the client but you don’t know when or if the client is going to postback that page to the server, so you would need to store view state at least until the session expires.
This could lead to a waste of server resources, as all those view states are being stored for users that may never postback to the server. If you keep your view state slim you’ll agree that the best place to store it is to send it with view.
Finally, if you’re still not happy with the view state on the client you can override the
SavePageStateToPersistenceMediumandLoadPageStateFromPersistenceMediummethods of the page and save it to another medium. I’ve already heard many people complain about view state on the client, and most time I just tell them to go ahead and implement persistence to another medium on the server… however, I believe no one ever did, probably because it’s complicated and you’ll end up with a solution that’s not that clean.