large objects in viewstate - bad idea?

[Steve Richter]

I have some potentially large objects I would like to store in the
viewstate of a user control. Large as in an entire email message. Is
ViewState not the sort of place to store such an object?

I think my question and concern depends on what asp.net does with the
view state when the page is written to the browser. Is the entire
viewstate contents written to the browser as a hidden field? Or are
the view state contents stored on the server and only a key of some
sorts is written to the browser?

thanks,

-Steve

 

[Steve Richter]

ok, I read that the entire viewstate is copied to the browser. So a
million byte email message in viewstate is not a good idea .

Session state is all server, correct? I can generate a guid key, store
my large serialized object in session state, and store the guid key in
the view state of the user control?

thanks,

-Steve

 

[Rick Strahl [MVP]]

Hi Steve,

Everything is relative <g>...

Viewstate is sent back and forth between the server and the client, so it
gets embedded into the page when it's created and sent back to you when the
form is POSTEd. As you might expect that creates overhead in terms of hte
size of the page being transferred. In addition ASP.NET has to encode
viewstate (both encrypt and then base64 encode if EnableViewStateMac is
true) which also has some overhead.

I try to avoid viewstate whenever I can, but there are some scenarios where
viewstate can be very beneficial in performance and maintaining state on a
page.


+++ Rick ---

--

Rick Strahl
West Wind Technologies
www.west-wind.com
www.west-wind.com/weblog

 

[Brock Allen]

Well, it's not necessarily a bad idea to put large items in ViewState, but
you pay the cost by doing so. Yes it's stored in a hidden input. In ASP.NET
2.0 there's a PageAdapter that can be configured to store the ViewState in
Session state, thus minmizing ViewState. You can do this yourself in v1.x
by overriding SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium.

-Brock
DevelopMentor
http://staff.develop.com/ballen

 

[Scott M.]

Whatever you do, you should consider a compression technique to reduce the
actual amount of data stored.

 

[Steve Richter]

Whatever you do, you should consider a compression technique to reduce the
actual amount of data stored.

is such a thing part of .net?

 

[Guest]

Hi,

won't using a compression technique increase the overhead?

Also, This would have to be manually handled by the programmer to compress
the data of the control then put it in viewstate and later to uncompress the
data to process it.
or does Asp.Net provide a easy way to do this?

 

[Scott M.]

I don't believe so, but there are many 3rd party solutions to this problem.

 

[Scott M.]

Why would compressing the data increase overhead? I don't believe .NET
includes compression classes, but there are 3rd party classes that can do
this. If you were able to reduce the size of the data by 50% (the OP said
he wants to store text from emails so 50% is very reasonable), the bandwidth
savings would negate the processing time needed to do the compression.

 

[Lau Lei Cheong]

And if you don't mind using API, there is LZ32.dll (the LZ* functions).

 

[Lau Lei Cheong]

Plus get around the 4K viewstate limit imposed by some proxy server, I would
say.