Should I use Viewstate in ASP.NET?

Question

I am moving from classic ASP to ASP.NET and have come across what many of you already know as a "viewstate". I could have jumped off the gun with my assumption, but it looks very bulky. In the past, I developed many ASP forms and never had a stateful problem. Is there any other way OR will I need to learn this ViewState thing in ASP.NET? I am using Visual Studio 2008, VB.NET as the code for the language and Framework v3.5 with SQL Server 2005.

Answer 1

You don’t have to. Check out the MVC framework . It excludes ViewState and works like an old ASP (at least from this point of view).

Answer 2

This series of posts must be read to understand ViewState.

I disabled it and do most of my work in Page_Init instead of Load (the values ​​are still persisted due to the ControlState). This setting worked for me.

Answer 3

ViewState is optional but useful. What is a ViewState is all the changes that occur in a control on the SERVER SIDE side. So, if you assign text to a label, and you want this text to be saved without having to reassign it with every postback, then you want to save it. Another example, when I always leave ViewState on, is something related to the data.

However, there are times when it is useful to disable ViewState for the same reason. For example, one place where I always disable ViewState is the MESSAGE label. Thus, when I have to print a message to the user (which should appear only once, and then leave), I just add the text to the shortcut and then forget about it. During the next PostBack, the label will automatically return to the text that is contained in the ASPX declaration for this control (in this case, an empty line).

Now note that this has nothing to do with the collection of forms, which are values ​​submitted to IIS during PostBack. A collection of forms sends values ​​that the user enters into form elements (text fields, check boxes, jerks, etc.). These .NET will be filled in the appropriate place - and this will happen after the ViewState has been processed.

Thus, if you send a text field with the phrase "hi there" to the client, the user changes it to "See ya" and then submits the form, then that will have a text field at the time the Page_Load event occurs, the text field with "See ya" in the TEXT attribute.

Answer 4

In classic ASP, we always used the HIDDEN field to do the job. Viewstate is just a way to do this automatically for you. Believe me, the learning curve is not as high as you think.

Answer 5

Some controls are severely crippled when you turn off the ViewState, so be prepared to solve these problems. The easiest way to be lazy and leave it, but uncontrolled, ViewState can easily account for 30% of the size of your HTML.

For example, let's say you have DropDown and you bind it to the Fruits list. You bind it in the if (! IsPostBack) {} block when the page loads. If you disable ViewState, you will lose items when you click the button. They should be attached to each page load. You will also lose your selected index, so you will need to disable the Request.Form [] variables.

Answer 6

Viewstate is part of the package when you work with ASP.NET. For the base page / website you do not need to “know” how to use Viewstate. It is just used when you put controls on pages.

It is very difficult to avoid Viewstate with ASP.NET because even if you disable it at the project level, some individual controls still use Viewstate to save their information.

If you don't want to deal with ViewState, consider using the ASP.NET MVC framework. Most likely, you will be more comfortable working with the MVC infrastructure coming from the classic ASP.

Answer 7

ViewState is completely optional in almost all cases, if not in all cases. ASP.NET automatically fills in the fields, even if ViewStateEnabled = false. I have been using ASP.NET for 5 or 6 years and should never have been dependent on ViewState. I will even turn it off when I can.

Answer 8

ViewState works automatically for the most part. This is just how ASP.NET keeps track of the current state of all controls.

You can also use viewstate manually if you want to save some additional data. It is as simple as:

Viewstate["Key"] = value; 

The only caveat is that any object you store in the viewstate should be serializable.

Answer 9

I can definitely recommend avoiding ViewState in DataGrids and DropDownLists, because I recently started doing it myself. I did not do this for fun, I had to fix a page that grew so large that it caused other problems. But it turned out to be easy, and the results were so dramatic that I am very pleased. Of course, this is not necessary for a small simple application or for small amounts of data, but, on the other hand, it’s good to be consistent (always go from known to known so that you can constantly improve your process ...) and why carry around excess baggage, ever?

This will require a little manual intervention on your part. For example, if you turn off the viewstate for the drop-down lists, you will need to reinstall them with each postback, and then restore the SelectedValue from the Request object. You will need to read about it, but google has a lot of information available.

Answer 10

Viewstate is automatically saved for asp.net controls "rooted" in the page. You have little to do, the values ​​and some other information are transmitted in a hidden input B64. You can look at it if you want, but it does not matter, all this is automatically processed for you.

Answer 11

If you write code for your own consumption, you can just turn it off and not worry.

Presumably, you are going to support Web Forms code written by other people, so you should know what configuration options and pain points are. First of all, I can think of

• how to disable it at the site, page and management level
• Why MachineKey Matters in Web Farms
• why your event log is full of ViewStateAuthentication errors.
• What is ViewStateUserKey

In terms of a real learning curve, this is probably a complete introduction to several MSDN articles.

Answer 12

ViewState is a necessary evil inherent in the metaphor of web forms. I personally find this methodology obsolete, bloated and, as a rule, not friendly to the web interface. Better check out the MVC structure as suggested above.

I suggest that you avoid the temptation to use ViewState as a "cache" to transfer data back and forth (I saw how websites do this because of cluster configuration and without the state of SQL support). The data is serialized and added to the page and must make callbacks for each request, adding to the total page size and slowing down the loading of your site.

Answer 13

 '<%@ Control Language="C#" AutoEventWireup="true" CodeFile="HomePage.ascx.cs" Inherits="HomePage" %> <script runat="server"> void testHF_ValueChanged(object sender, EventArgs e) { this.HFvalue.Text = this.testHF.Value ; } </script> <asp:Label ID="UserNamelbl" runat="server" Text="User Name : " Visible="false"></asp:Label> <asp:TextBox ID="UserNametxt" runat="server" Visible="false" ></asp:TextBox> <asp:Label ID="HFvalue" Text="......" runat="server"></asp:Label> <asp:HiddenField ID="testHF" OnValueChanged="testHF_ValueChanged" value="" runat="server" ></asp:HiddenField> <input type="submit" name="SubmitButton" value="Submit" onclick="CL()" /> <script type="text/javascript"> function CL() { this.testHF.Value = this.UserNametxt.Text; } </script> '