Storing datatable in ViewState

Question

I was reading this article from Microsoft about the state management.

http://msdn.microsoft.com/en-us/library/75x4ha6s(v=vs.100).aspx

I found an interesting thing here. ViewState is categorized as Client Side option (Although I already knew that). It reminds me of our code in the application.

DataTable dt = getDatatableFromDB();
ViewState["dataTable"] = dt;

And this code is working fine at the moment.

My confusion is :

1. How can a client side object(ViewState) save Server side object(Datatable)?
2. Is it a good practice to use ViewState for storing large objects like Datatables?
3. What possibly could be the side effect(if any) if we keep on using this approach?

Solution 1

The viewstate is stored in a hidden <input /> tag on the form. When the user initiates a postback (by clicking a button, for example), the data is returned to the server as part of the form data.

If you store large amounts of data in the ViewState, you will incur a penalty both when the user attempts to download the page (because all that data will be part of the HTML) and when the user attempts to submit the form (because all that data must be uploaded back to the server).

In addition, the ViewState is easily lost. It is only preserved as long as the user is submitting the form. If the user clicks a hyperlink to another page, the form is never submitted and all the data contained within the ViewState is lost. This is true even if the anchor tag points back to the page the user is currently on.

I see from your previous question that you are trying to find a good place to put your DataTables. ViewState is not the worst place as long as the data is relatively small. Base64 is better than XML in terms of memory usage but it is still a long way from efficient. If the data is fairly static, you may want to consider storing it in the ApplicationState. If you are editing the DataTable with a GridView, then the GridView is actually already storing the DataTable for you which you can access via the DataSource property (just cast it back to a DataTable).

---

It is also worth noting that while the ViewState data is encoded in base64 (meaning the average user will not be able to understand it), it can be easily edited by a determined user. Seemingly innocuous data could be edited to become quite harmful to your website. This is a classic avenue for hacking a website, so you must be very careful about what data, exactly, you are storing. For example, if you store the user's ID in the ViewState, the user could edit the ID and hack into another user's account. (Note: this is only an issue if EnableViewStateMac has been set to False.)

Solution 2

1) How can a client side object(ViewState) save Server side object(Datatable)?

It is serialized.

2) Is it a good practice to use ViewState for storing large objects like Datatables?

It depends on your environment and requirements.

3) What possibly could be the side effect(if any) if we keep on using this approach?

A lot of data will be going over the wire. It could slow things down.

Comments

[Simon Whitehead]

Side note: It is serialized into the input value and deserialized on its way back.

[Simon Whitehead]

Another side note: Serializing a large object will also cause it to slow down.. not just the wire transfer.

[Usman Khalid]

@Cyborgx37, Will enableViewStateMAC help in the case of editing ViewState?

[JDB]

Yes, EnableViewStateMac will go a long way toward preventing ViewState hacking.

[Usman Khalid]

@Cyborgx37 Yes I have read about the Application. But Application will be shared plus it is using server's memory. And we don't have control over the Application memory management like we have with Cache. So if I am going to select between Application and Cache, my vote is for Cache.

[JDB]

I should have elaborated on "static" - I meant to also include that the data is the same for all users (for example, a lookup table). In that case, the memory footprint would be negligible. But it all depends on your project, obviously.