Is assigning a DataTable ViewState a good way?

Question

I get the DataTable from the database and assign the ViewState as shown below: Because I do not want to hit the database every time.

DataTable dt = GetDataTable(); ViewState["dtTable"] = dt; 

GetDataTable() is a method that retrieves 1000 records from a database. Is this the best way, or which one is the best way to handle this?

Answer 1

First of all: explanations aside, it still depends a lot on your requirements, environment settings ...

The view state is stored in a hidden field that appears as the <input /> in the final HTML sent to the browser. When the user initiates the postback (Button Click, etc.), the data is sent back to the server as part of the provided form data.

If you store a large amount of data in ViewState, you will have to incur a fine when the user tries to load the page, because all such data will be part of your HTML, and also when the user tries to submit the form, because again this data will be sent back to the server.

In addition, ViewState is easily lost. It is saved only as long as the user submits the form. If the user clicks a hyperlink to another page, the form is not submitted, and therefore the data contained in the ViewState is lost.

It is recommended to use ViewState if the data is relatively small.

If we look at security options, ViewState data will be encoded in base64, which can be easily decoded. This is a classic example of a website hack, so cross-check what data you store. Although you can solve this problem by setting EnableViewStateMac to true.

For large amounts of data, a session is a good option. If you can detect when a user is executed with a specific data block, set the Session variable to null to withstand the memory overhead. You cannot always do this, but the session will expire and the memory will be automatically fixed. Reducing the session timeout can also help, but set it according to your needs.

In addition, the data in the session is actually present on the web server between page loads. This helps reduce page size, but only to use session id.

One recent option is to use Caching.Check MSDN here for best caching practices.

Answer 2

Viewing side effects from the side

1) Serializes to input value and deserializes on the way back.

2) The presentation staff is stored in a hidden tag in the form. When the user initiates a postback (for example, by clicking a button), the data is returned to the server as part of the form data. This may slow down the work.

3) ViewState is easily lost. It is saved only as long as the user submits the form. If the user clicks a hyperlink to another page, the form is never submitted and all data contained in the ViewState is lost. This is true even if the anchor tag points to the page on which the user is currently logged on.

I would use ASP.NET Cache to store this data for the following reasons.

1) The cache has expiration, which means that you can automatically delete it based on rolling or absolute latency

2) The cache is automatically deleted if the "pressure" process is too high.

3) You can make the cached item specific for one user or global for all users based on its key

Answer 3

ViewState is not a bad way, but when on big data it’s better to save your data in a session variable, the expiration of which you can control,

Answer 4

Using a DataTable will work. However, a DataTable is basically a dynamic object, and code in a view is usually difficult to debug.

I would suggest creating a class or structure that contains the properties you need. Then convert the DataTable to list instances of this class and send it to the view.

This will make the code more readable, because now any programmer can see what data you are trying to extract. And that will not allow you to debug the presentation a lot.

Answer 5

View state is a good way to keep a data table in view state

Store the data table in viewstate DataTable dt = new DataTable (); ViewState ["dttable"] = dt;

And now the ViewState data in Datatable

DataTable dtnin = (DataTable) ViewState ["dttable"];