MVP: Should I put serializable custom object in viewstate

[Lily]

I create a object called customer and with properties, such as first
name, last name, etc and method like GetCustomer, UpdateCustomer, etc.

I had a datagrid to display the customers list. Then user select one
customer to update it. The datasource of datagrid will be the an
arraylist which is object -- customers collection. So I put the
selected customer information into the viewstate. When the page is
post back, I could highlight the one which is selected in the previous
page. I just wonder if I should put serializable custom object in
viewstate. Please reply me if you have any thought.

thanks,
Lily

 

[Lau Lei Cheong]

I'm not a MVP, but I'm able to tell you a) viewstate has size limit, and b)
it'll cause you roundtrip eat more bandwidth(as the serialized string will
be stored in hidden field and pass back on posting), so you had better avoid
it if you can, and use Session object unless you have better reason.

 

[CT]

As Lau Lei pointed out, it really depends on the size of your custom object.
The bigger object the longer the server roundtrip will take. One alternative
is the Session object. In your case I'd probably opt for the ViewState
because the ViewState for a page is automatically discarded once you move
away from the page, whereas Session state remains for the entire session.

 

[S.M. Altaf [MVP]]

If bandwidth is a concern, store a reference (instead of the actual object) to the selected customer in your viewstate/session object so that the logic in your page does the highlighting for you.

HTH
Altaf [MVP]



--------------------------------------------------------------------------------
All that glitters has a high refractive index.
www.mendhak.com
I create a object called customer and with properties, such as first
name, last name, etc and method like GetCustomer, UpdateCustomer, etc.

I had a datagrid to display the customers list. Then user select one
customer to update it. The datasource of datagrid will be the an
arraylist which is object -- customers collection. So I put the
selected customer information into the viewstate. When the page is
post back, I could highlight the one which is selected in the previous
page. I just wonder if I should put serializable custom object in
viewstate. Please reply me if you have any thought.

thanks,
Lily

 

[Guest]

Viewstate is simply an "encrypted" store on the client side. If you view
source on the page, you will see it as a hidden input tag. The implications
here are that anything you store in ViewState gets roundtripped with every
postback.

If the object is small enough, or you have complete control over bandwidth
(Intranet), you can store in ViewState. Make sure the object only has Page
scope or you will be kludging to persist it. If not, you can persist the
object on the server side and send a reference "token" (something you create)
to ViewState; better a 128 bit GUID (worst case) than a 20k object.

I would not be overly concerned about ViewState size unless you are
attempting to store huge data result sets in ViewState.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

While I agree that loading huge objects in ViewState is a bad idea, loading
Session is also a bad idea in most instances, as the objects have a wider
scope. Here are a couple of potential problems:

1. Same Session object used on multiple pages as Page scoped objects. Set
once, read everywhere, even if you do not want to.

2. Session objects live too long. While this is not a problem on many sites,
if the traffic grows and you are sticking a few hundred K in Session, you
could burn a lot of memory until Session timeout.

At times, you end up figuring the balance between persistent information
(normally stored on file sys or in a database (more commonly a database) and
in memory cache.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Rob Schieber]

Viewstate is simply an "encrypted" store on the client side. If you view
source on the page, you will see it as a hidden input tag. The implications
here are that anything you store in ViewState gets roundtripped with every
postback.

If the object is small enough, or you have complete control over bandwidth
(Intranet), you can store in ViewState. Make sure the object only has Page
scope or you will be kludging to persist it. If not, you can persist the
object on the server side and send a reference "token" (something you create)
to ViewState; better a 128 bit GUID (worst case) than a 20k object.

I would not be overly concerned about ViewState size unless you are
attempting to store huge data result sets in ViewState.

Cowboy, I hate to nitpick, but I think its a mistake to state that
Viewstate is encrypted. It is base 64 encoded which is much different
than conventional encryption. I agree with everything else you said though.

 

[Kevin Spencer]

He put it in qutes. He knows.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.