views:

1410

answers:

12

I am moving from classic ASP to ASP.NET and have encountered what many of you already know as "viewstate". I might be jumping the gun with my assumption, but it looks highly cumbersome. I have developed many ASP forms in the past and never had issues with keeping state. Is there another way OR am I going to have to learn this Viewstate thing in ASP.NET? I am using Visual Studio 2008, VB.NET as the code behind language and Framework v3.5 with SQL Server 2005.

+3  A: 

In classic ASP we always just used a HIDDEN field to do the job. Viewstate is just a way of doing that for you automatically. Trust me the learning curve is not as high as you might think.

Josh
It is comforting to hear that (re: learning curve). :-)
Optimal Solutions
I did lots of classic ASP and when I first moved to ASP.Net it blew my mind. However once you get used to the model it is pretty nice compared to the old way of doing things. I will be happy if I never have to look at another ADO record set again :)
Josh
I am currently in that "its blowing my head apart" mode. :-) Like everything else, one day it will just happen.
Optimal Solutions
+2  A: 

ViewState is completely optional in almost all if not all cases. ASP.NET re-populates fields automatically even if ViewStateEnabled=false. I've been using ASP.NET for 5 or 6 years and have never had to depend on ViewState. I even disable it when I can.

Mark Cidade
I am going to have to experiment with this. Thank you for your response.
Optimal Solutions
Learn the difference between ViewState and ControlState
John Sheehan
+4  A: 

You don't have to. Check out MVC framework. It eliminates ViewState and works as old ASP (at least from this point of view).

Biri
Thank you. I am going to check this MVC stuff out.
Optimal Solutions
+1  A: 

Viewstate is kept automatically for asp.net controls "rooted" to the page. There is little you have to do, the values and some other information is passed in a hidden input B64 encoded. You can look at it if you want, but it doesn't matter, it's all handled automagically for you.

stephenbayer
I had begun to look at that encoding and thought "man! wth is that?!" and read up on it but did see or know if there was an alternative. Bri says to look into the MVC framework and I probably will. Thx!
Optimal Solutions
+2  A: 

Some controls are deeply crippled when you turn ViewState off, so be prepared to address these concerns. It's easiest to just be lazy and leave it on, but left unchecked, ViewState can easily account for 30% of the size of your HTML.

For example, say you have a DropDown, and you bind it to a list of Fruits. You bind it in the if(! IsPostBack) { } block in the page load. If you turn off ViewState, you'll lose the items when you click a button. They need to be bound every page load. You'll also lose your selected index, so you'd need to pull that off of the Request.Form[] variables.

Ben Scheirman
The size was one concern. The other concern is the "unknown" and learning curve - which I see from these answers might not be as bad as it looks. Thanks!
Optimal Solutions
+2  A: 

Viewstate is part of the package when you are working with ASP.NET. For a basic page/website you shouldn't have to 'know' how to use Viewstate. It just gets used as you put controls on pages.

It's pretty hard to avoid Viewstate with ASP.NET because even if you turn it off at the project level, some individual controls still use Viewstate to persist their information.

If you don't want to deal with Viewstate, consider using the ASP.NET MVC framework. You will likely be more comfortable with the MVC framework coming from Classic ASP.

Chris Sutton
+2  A: 

ViewState works automatically for the most part. It's just how ASP.NET keeps track of the current state of all it's controls.

You can manually use viewstate too, if you want to store some extra data. That is as simple as:

Viewstate["Key"] = value;

The only caveat with that is that any object you store in viewstate must be serializable.

Telos
good to know that!
Optimal Solutions
+1  A: 

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

Presumably you're going to maintain Web Forms code written by other people, so you should know what the config options and pain points are. Top few I can think of

  • how to disable it at site, page and control level
  • why MachineKey is relevant in web farms
  • why your event log is full of ViewStateAuthentication errors
  • what ViewStateUserKey is

In terms of actual learning curve this is probably a thorough read of a couple of MSDN articles.

alexis.kennedy
Thanks for the help. I need to set aside some time to read those MSDN articles. I just liked the fact that over 10 years ago I was able to dive right into ASP with nothing more than notepad and had a fairly sizable application done within a couple of hours. Its not gonna be like that this time.
Optimal Solutions
+1  A: 

ViewState is a necessary evil inherent to the web forms metaphor. I personally find this methodology obsolete, bloated and generally not web-friendly. Better check out MVC framework as suggested above.

I suggest you avoid the temptation to use ViewState as a "cache" to pass data back and forth (I've seen websites doing this because of clustered setup and no SQL-backed session state). The data is serialized and added to the page and must do roundtrips every request, adding to the total size of the page and making your site slower to load.

axel_c
+2  A: 

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

This will require a little manual intervention on your part. For example, if you turn off viewstate for drop down lists, you'll need to rebind them on each postback, and then restore the SelectedValue from the Request object. You'll need to read up on this, but google has lots of readily available information.

Mike
+3  A: 

ViewState is optional, but helpful. What ViewState is, is all the changes which occur on a control on the SERVER SIDE. So, if you're assigning text to a label, and you want that text to persist without the need to reassign it on every postback, then you'll want to maintain that. Another example where I always leave ViewState on is anything databound.

That said, there are times when it's helpful to turn ViewState off for that same reason. For example, the one place where I always turn ViewState off is a MESSAGE label. That way, when I have to print out a message to the user (one which should only appear once and then go away) I just add the text to the label and then forget about it. During the next PostBack, the label will automatically revert to the text which is found in the ASPX declaration for that control (in this case an empty string).

Now, note that this has nothing to do with the form collection, which are the values posted to IIS during the PostBack. The form collection sends the values that the user enters into form elements (textboxes, checkboxes, droplists,etc). These .NET will populate into the appropriate place--and this occurs AFTER ViewState has been processed.

This way, if you send a textbox with the phrase "hi there" to the client, the user changes it to "See ya" and then submits the form, what the textbox will have by the time the Page_Load event fires is a textbox with "See ya" in the TEXT attribute.

Stephen Wrighton
+6  A: 

This series of posts is must reading for understanding ViewState

I disable it and do most of my work in Page_Init instead of Load (values are still maintained because of ControlState). This setup has worked out well for me.

John Sheehan