Is it common behaviour to turn of the EnableViewstate on some control on the page

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hello!

I just wonder assume there exist some pages that are used in production
WebSite and there are a normal number of controls
on these pages is it then a common behaviour to set EnableViewState=false on
some of these control..

I have never done any WebSite that have been used in production that's why I
ask or is first when you have performance problem you start to do some
tuning for example to switch off theViewState on some control such as Label.

//Tony
 
I just wonder assume there exist some pages that are used in production
WebSite and there are a normal number of controls
on these pages is it then a common behaviour to set EnableViewState=false on
some of these control..

I have never done any WebSite that have been used in production that's why I
ask or is first when you have performance problem you start to do some
tuning for example to switch off theViewState on some control such as Label.
Click to expand...

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

has a section on viewstate.

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

ditto.

But this is one of these optimizations that should only
be applied, when you know you have a problem.

Viewstate on is the default and and the model web forms
is built on.

If you really dislike the model, then maybe
ASP.NET MVC will suit you better.

I have also seen it suggested that using
HTML controls instead of Web controls can
be an option to avoid too much "behind the scene".

Arne
 
Hello!

I just wonder assume there exist some pages that are used in production
WebSite and there are a normal number of controls
on these pages is it then a common behaviour to set EnableViewState=false on
some of these control..

I have never done any WebSite that have been used in production that's why I
ask or is first when you have performance problem you start to do some
tuning for example to switch off theViewState on some control such as Label.

//Tony
Click to expand...

It's definitely not *uncommon* to not use view state.

It really depends on the kind of site you're creating. If it's just a
thin "homepage", like a corporate "this-is-who-are-and-what-we-do" site,
then using viewstate probably will not have a significant impact.

If you're writing a complete web app OTOH, then the viewstate might turn
out to be a significant portion of the page size that has to be returned
to the client.

In general, always evaluate whether to use viewstate (I tend to avoid
it, if possible). In lots (if not most) of cases, the handling can be
done client-side, without postbacks, resulting in better user
experience, and less overhead.

The obvious drawback of course is that more clientside coding is required.
 
Hello!

I just wonder assume there exist some pages that are used in production
WebSite and there are a normal number of controls
on these pages is it then a common behaviour to set EnableViewState=false on
some of these control..

I have never done any WebSite that have been used in production that's why I
ask or is first when you have performance problem you start to do some
tuning for example to switch off theViewState on some control such as Label.

//Tony
Click to expand...

It's definitely not *uncommon* to not use view state.

It really depends on the kind of site you're creating. If it's just a
thin "homepage", like a corporate "this-is-who-are-and-what-we-do" site,
then using viewstate probably will not have a significant impact.

If you're writing a complete web app OTOH, then the viewstate might turn
out to be a significant portion of the page size that has to be returned
to the client.

In general, always evaluate whether to use viewstate (I tend to avoid
it, if possible). In lots (if not most) of cases, the handling can be
done client-side, without postbacks, resulting in better user
experience, and less overhead.

The obvious drawback of course is that more clientside coding is required.
 
Big said:
as Label.

Most Web developers who develop enterprise level Web solutions on the
client side disabled viewstate period, and they do not use viewstate
under any circumstances. They are concerned about speed and
responsiveness out the gate.

If they keep state data on a page, then a hiddenfield is used only to
keep small amounts of data in state, like a flag. The key is to keep
unnecessary data off the wire over HTTP between the client and the
server. This is a development standard in shops to keep viewstate disabled.
Click to expand...

If you like ViewState (or, sensibly, dislike writing a lot of
client-side Ajax code) then you can always store the ViewState in a
database. Here's one way of doing that:
http://weblogs.asp.net/adweigert/archive/2004/03/09/86628.aspx

Also, don't forget that enabling gzip compression within IIS can also
make a big difference to page sizes - and is something that many people
haven't bothered to do.
 
as Label.

Most Web developers who develop enterprise level Web solutions on the
client side disabled viewstate period, and they do not use viewstate
under any circumstances. They are concerned about speed and
responsiveness out the gate.

If they keep state data on a page, then a hiddenfield is used only to
keep small amounts of data in state, like a flag. The key is to keep
unnecessary data off the wire over HTTP between the client and the
server. This is a development standard in shops to keep viewstate
Click to expand...
disabled.

Well - I suggest that the OP tries to open view source on:

http://www.microsoft.com/

When he sees that it uses view state, then he can think about
whether MS is not an enterprise or your knowledge about practices
in enterprise is lacking.

Arne
 
The other way is to use a session object. Data from a textbox is saved
in a string property of a custom object that has many properties and
other objects/object graphs in it concerning user information or whatnot
and the object is keep in session. The object is sent down to the BLL
and DAL to be verified and persisted to a database.
Click to expand...

Session has (surprise) session scope while viewstate has page
scope.

I can mean a functional difference.

Web apps that rely heavily on session may not work if the user
has two open tabs on the same site.

Arne
 
Also, don't forget that enabling gzip compression within IIS can also
make a big difference to page sizes - and is something that many people
haven't bothered to do.
Click to expand...

That is a very good advice.

It has a huge impact on sizes (usually a lot more than
disabling viewstate) and does not impact functionality.

It cost a little bit in CPU.

But I think success rate of doing it is close to 100%!

Arne
 
You can make the session object unique enough by using a Guid that is
being keep on each page, Guid in state on a hidden field, that's used to
derive the object's name to save to session and restored back from
session the object in this case. I have been there and done that.
Click to expand...

Absolutely.

But in that case it is not disabling the by page info but
just keeping the information server side.
In this same situation, the session object was being serialized and
saved to a database table so that if an IIS reset happened which
happened numerous times or session timeout and the user walked away for
days, they could pick back up where they left off like nothing had
happened and continue the session as the session object was retrieved
from the database and put back into session for the page on any of the
several pages used in this particular application.
Click to expand...

Making session info survive a restart makes more reliable software
(using a database is a rather primitive way, but it is one way).

Note that having state client side also makes it survive a restart.

It is not simple and probably not desirable to try and restore
session when a user comes back after session timeout.

Arne
 
It's a protected and secure way of doing it, if you have information
that must be protected.
Click to expand...

But it goes on disk, which is usually not required.

It seems required in your case though per below requirement.
When you are given requirements that it must happen, then you do it with
no if(s) and/or but(s) about it.
Click to expand...

True.

Arne
 
Back
Top