Why is the viewstate serialized to a hidden field in the form and not stored on the server?

I am new to WebForms and I am trying to understand ViewState. AFAIK today, it saves user interface modifications over postback on the same page. But why does he send the state to the client (= saved changes) and not save it on the server , saving cycles and processor bandwidth?

Do I understand something completely wrong?

+4
source share
2 answers

The state of a view is something internally related to the view, as the name implies, and trying to manage it individually while maintaining this relationship is not something that is easy to do.

You will need to save the view state on the page, so you still have to send an identifier to the client in order to be able to get the correct view state during postback. Another serious problem is that you send the page to the client, but you donโ€™t know when or when the client will send this page to the server, so you will need to save the view state at least until the session expires.

This can lead to a waste of server resources, since all these view states are saved for users who can never send messages back to the server. If you keep your status in a subtle state, you will agree that the best place to store it is to send it with a submission.

Finally, if you are still not happy with the state of the presentation on the client, you can override SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium and save it on another medium. I have already heard that many people complain about the viewing status on the client, and in most cases I just tell them to continue and implement the transfer to another media on the server ... however, I believe that no one has ever done this, probably , because it was complicated and you get a solution that is not so clean.

+3
source

ViewState is used when the page is writing back to restore the control tree on the page to what it was when the last page was viewed.

This allows you, for example, to control the GridView so that it maintains the state (what is shown in the GridView) on the reverse side, without resetting it to the same data.

The reason the ViewState is serialized and sent to the client by default (I think) is that this is the easiest way to get it back when the client sends the message back.

What if, for example, the user has several browser windows open with the same loaded page, and you have a view repository stored in the session? Assigning the correct view to different windows in this case, of course, can be allowed, but provided that the client explicitly published it, this is the easiest way.

However, you can have a view repository stored in the session. See for example this link .

Other features are available by implementing your own System.Web.UI.PageStatePersister .

+2
source

All Articles