views:

660

answers:

3

We're about to start rebuilding one of our ASP.NET projects and I would like to try developing it without viestate turned on (disabled in web.config).

I know about the upsides and downsides of viewstate and generally speaking what it keeps track of in comparison to control state, however I would like to know:

  1. What are the principle development process differences? Ie how differently do you structure your Page_Load etc?

  2. Is there any functionality in the standard ASP.NET controls that really will just not work without viewstate turned on?

Also, are there any detailed articles on the workflow differences between working with and without VS?

+1  A: 

I disable viewstate on my projects. I use scatter/gather methods to populate and get values from the aspx pages to/from my data access objects. It is a lot cleaner and simpler than using viewstate.

Otávio Décio
Thanks ocdecio, what do you mean by scatter/gather methods? Do you use the rest of the ASP.NET page/event model?
Kieran Benton
Yes, I use the normal page event model. Gather = collect values from page elements into my objects; scatter = populate page elements with values from my objects.
Otávio Décio
+1  A: 

If you are that against viewstate - why not try using the MVC framework? It may be an easier adjustment.

rifferte
+1  A: 

Most controls like TextBoxes and DropDownLists will function perfectly well without viewstate.

I don't know of any development process issues, other than any controls or properties created or modified through code will not persist without viewstate, so you would have to recreate/modify them on a postback.

I have some very big pages with large viewstates. I did an experiment to disable viewstate for the entire project, and found (at first) no noticeable loss of functionality. Then a few little issues came up in testing, so we reinstated it. But our 300 page web app was probably 99% functional without viewstate. The issues we had were centred around datagrids - paging mainly, and dynamically created controls and other things modified by code behind, and thus not persisted without viewstate.

This is a very good article on Viewstate:

http://msdn.microsoft.com/en-us/library/ms972976.aspx

MikeW