ViewState and SessionState both exist for good reasons, and there are times
when using one or the other is a good idea. ViewState doesn't take up server
resources (memory), but it can slow down response time from the server due
to the amount of data being transmitted to the browser, and is only
persistent at Page scope. That is, ViewState only lives as long as the
current WebForm is loaded and posting back to itself. Once the user
navigates away from that Page, ViewState is lost. SessionState lasts an
entire single user Session, and is persistent across Pages. It does consume
some server resources during its lifetime, and can time out. Keeping these
in mind, and handling their eventualities should make SessionState a viable
storage persistence medium for objects with Session scope.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
"jenn" <an*******@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com...
Hi,
I was using Sessionto persist datatables, but now I don't think it's good
idea to do so as Session can cause overhead on the server (as the number of
users grow), so I use ViewState to store the datatables instead.
I'm wondering what are the disadvantages of using ViewState against
Session, beside the fact that the former slows the rendering of HTML as well
as the data is visible to the user.
Are there other issues I should be concerned about, such as memory
overhead on the server, as the number of users grow? Are ViewState values
unique to a session/page, or are they of application level? Is there a need
for ViewState clean up (sounds silly because I think the answer is no, but I
want to make sure)
Thanks in advance for any reply.