Search:  
NamespacesDiscussions.NET v1.1Feedback
Best practices for minimising ViewState
Messages   Related Types
This message was discovered on ASPFriends.com 'aspngcontrolscs' list.


Michael
Does anyone out there have any tips for how control developers can
generically keep control state whilst keeping the use of ViewState to an
absolute minimum ?

Using ViewState to record a control's settings seems to quickly become very
costly in terms of the page load times/HTML byte sizes. The documentation
seems to suggest that if you have properties or other state data that can be
altered at run time the ViewState should be used to hold that data. This
seems to be a little inefficient as property values set at design time can
end up in the page's ViewState.

Ideally I'd like to only store information in the ViewState when it has been
set at runtime. I can't seem to find a way of easily differentiating
between property changes as a result of design time assignments and other
property changes such as from a postback.

One possible approach is to mark all the properties of the control with the
DesignOnly(true) attribute, and then supply methods (which utilise the
ViewState) for use at runtime, and then in the LoadViewState restore state
data only if it exists:-

object viewStateData = ViewState[viewStateKey];
if (viewStateData != null)
myDataMember = (ADataType)viewStateData;

It will work but having two points access for every setting of the control
seems a little costly in terms of code maintainability.

Another approach is by default to disable the use of ViewState and then
supply flags to enable ViewState individually for each property:-

public string MyProperty { ..... }
public bool MyPropertyEnableViewState { ..... }

This approach seems like a bit more of a kludge.

What do you think of either of these approaches ?
Can anyone out there think of a better approach ?

Michael Lang
MS .NET Developer
Ph: +61 0417-498-620
www.michaellang.com.au
Reply to this message...
 
    
Nikhil Kothari
WW91IGRvIG5vdCBoYXZlIHRvIGltcGxlbWVudCBhbnkgb2YgdGhpcy4NClZpZXdTdGF0ZSBpcyBh
bHJlYWR5IHNtYXJ0IGFib3V0IHJvdW5kLXRyaXBwaW5nIG9ubHkgdGhvc2UgdmFsdWVzIHRoYXQg
aGF2ZSBiZWVuIGNoYW5nZWQgZnJvbSB0aGVpciBpbml0aWFsIHN0YXRlLg0KIA0KVGhlIHN0dWZm
IHRoYXQgZ2V0cyBzZXQgZGVjbGFyYXRpdmVseSBvbiBhIHRhZyBpcyBwYXJ0IG9mIHRoZSBpbml0
aWFsIHN0YXRlLCBhbmQgaXQgZG9lc24ndCByb3VuZC10cmlwIGFzIHBhcnQgb2YgdGhlIGRhdGEg
aW4gdGhlIGhpZGRlbiBmaWVsZC4NCiANCk5pa2hpbCBLb3RoYXJpDQpBU1AuTkVUIERldmVsb3Bt
ZW50DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBNaWNoYWVsIFttYWls
dG86bWxhbmdAbWljaGFlbGxhbmcuY29tLmF1XSANCglTZW50OiBTYXQgNC8yMC8yMDAyIDg6MDQg
UE0gDQoJVG86IGFzcG5nY29udHJvbHNjcyANCglDYzogDQoJU3ViamVjdDogW2FzcG5nY29udHJv
bHNjc10gQmVzdCBwcmFjdGljZXMgZm9yIG1pbmltaXNpbmcgVmlld1N0YXRlDQoJDQoJDQoJDQoJ
RG9lcyBhbnlvbmUgb3V0IHRoZXJlIGhhdmUgYW55IHRpcHMgZm9yIGhvdyBjb250cm9sIGRldmVs
b3BlcnMgY2FuIGdlbmVyaWNhbGx5IGtlZXAgY29udHJvbCBzdGF0ZSB3aGlsc3Qga2VlcGluZyB0
aGUgdXNlIG9mIFZpZXdTdGF0ZSB0byBhbiBhYnNvbHV0ZSBtaW5pbXVtID8NCgkgDQoJVXNpbmcg
Vmlld1N0YXRlIHRvIHJlY29yZCBhIGNvbnRyb2wncyBzZXR0aW5ncyBzZWVtcyB0byBxdWlja2x5
IGJlY29tZSB2ZXJ5IGNvc3RseSBpbiB0ZXJtcyBvZiB0aGUgcGFnZSBsb2FkIHRpbWVzL0hUTUwg
Ynl0ZSBzaXplcy4gIFRoZSBkb2N1bWVudGF0aW9uIHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCBpZiB5
b3UgaGF2ZSBwcm9wZXJ0aWVzIG9yIG90aGVyIHN0YXRlIGRhdGEgdGhhdCBjYW4gYmUgYWx0ZXJl
ZCBhdCBydW4gdGltZSB0aGUgVmlld1N0YXRlIHNob3VsZCBiZSB1c2VkIHRvIGhvbGQgdGhhdCBk
YXRhLiAgVGhpcyBzZWVtcyB0byBiZSBhIGxpdHRsZSBpbmVmZmljaWVudCBhcyBwcm9wZXJ0eSB2
YWx1ZXMgc2V0IGF0IGRlc2lnbiB0aW1lIGNhbiBlbmQgdXAgaW4gdGhlIHBhZ2UncyBWaWV3U3Rh
dGUuICANCgkgDQoJSWRlYWxseSBJJ2QgbGlrZSB0byBvbmx5IHN0b3JlIGluZm9ybWF0aW9uIGlu
IHRoZSBWaWV3U3RhdGUgd2hlbiBpdCBoYXMgYmVlbiBzZXQgYXQgcnVudGltZS4gIEkgY2FuJ3Qg
c2VlbSB0byBmaW5kIGEgd2F5IG9mIGVhc2lseSBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBwcm9w
ZXJ0eSBjaGFuZ2VzIGFzIGEgcmVzdWx0IG9mIGRlc2lnbiB0aW1lIGFzc2lnbm1lbnRzIGFuZCBv
dGhlciBwcm9wZXJ0eSBjaGFuZ2VzIHN1Y2ggYXMgZnJvbSBhIHBvc3RiYWNrLg0KCSANCglPbmUg
cG9zc2libGUgYXBwcm9hY2ggaXMgdG8gbWFyayBhbGwgdGhlIHByb3BlcnRpZXMgb2YgdGhlIGNv
bnRyb2wgd2l0aCB0aGUgRGVzaWduT25seSh0cnVlKSBhdHRyaWJ1dGUsICBhbmQgdGhlbiBzdXBw
bHkgbWV0aG9kcyAod2hpY2ggdXRpbGlzZSB0aGUgVmlld1N0YXRlKSBmb3IgdXNlIGF0IHJ1bnRp
bWUsIGFuZCB0aGVuIGluIHRoZSBMb2FkVmlld1N0YXRlIHJlc3RvcmUgc3RhdGUgZGF0YSBvbmx5
IGlmIGl0IGV4aXN0czotDQoJIA0KCW9iamVjdCB2aWV3U3RhdGVEYXRhID0gVmlld1N0YXRlW3Zp
ZXdTdGF0ZUtleV07DQoJaWYgKHZpZXdTdGF0ZURhdGEgIT0gbnVsbCkNCgkgICAgbXlEYXRhTWVt
YmVyID0gKEFEYXRhVHlwZSl2aWV3U3RhdGVEYXRhOw0KCSANCgkNCglJdCB3aWxsIHdvcmsgYnV0
IGhhdmluZyB0d28gcG9pbnRzIGFjY2VzcyBmb3IgZXZlcnkgc2V0dGluZyBvZiB0aGUgY29udHJv
bCBzZWVtcyBhIGxpdHRsZSBjb3N0bHkgaW4gdGVybXMgb2YgY29kZSBtYWludGFpbmFiaWxpdHku
DQoJIA0KCUFub3RoZXIgYXBwcm9hY2ggaXMgYnkgZGVmYXVsdCB0byBkaXNhYmxlIHRoZSB1c2Ug
b2YgVmlld1N0YXRlIGFuZCB0aGVuIHN1cHBseSBmbGFncyB0byBlbmFibGUgVmlld1N0YXRlIGlu
ZGl2aWR1YWxseSBmb3IgZWFjaCBwcm9wZXJ0eTotDQoJIA0KCXB1YmxpYyBzdHJpbmcgTXlQcm9w
ZXJ0eSB7IC4uLi4uIH0NCglwdWJsaWMgYm9vbCBNeVByb3BlcnR5RW5hYmxlVmlld1N0YXRlIHsg
Li4uLi4gfQ0KCSANCglUaGlzIGFwcHJvYWNoIHNlZW1zIGxpa2UgYSBiaXQgbW9yZSBvZiBhIGts
dWRnZS4NCgkgDQoJV2hhdCBkbyB5b3UgdGhpbmsgb2YgZWl0aGVyIG9mIHRoZXNlIGFwcHJvYWNo
ZXMgPyANCglDYW4gYW55b25lIG91dCB0aGVyZSB0aGluayBvZiBhIGJldHRlciBhcHByb2FjaCA/
DQoJIA0KCU1pY2hhZWwgTGFuZw0KCU1TIC5ORVQgRGV2ZWxvcGVyDQoJUGg6ICs2MSAwNDE3LTQ5
OC02MjANCgl3d3cubWljaGFlbGxhbmcuY29tLmF1IDxodHRwOi8vd3d3Lm1pY2hhZWxsYW5nLmNv
bS5hdS8+IA0KCSANCgl8IFthc3BuZ2NvbnRyb2xzY3NdIG1lbWJlciBuaWtoaWxrb0BtaWNyb3Nv
ZnQuY29tID0gWU9VUiBJRCB8IGh0dHA6Ly93d3cuYXNwbGlzdHMuY29tL2FzcGxpc3RzL2FzcG5n
Y29udHJvbHNjcy5hc3AgPSBKT0lOL1FVSVQgfCBodHRwOi8vd3d3LmFzcGxpc3RzLmNvbS9zZWFy
Y2ggPSBTRUFSQ0ggQXJjaGl2ZXMgPCAvQkxPQ0tRVU9URSA+IA0KDQo=
Reply to this message...
 
    
Michael
Thanks Nikhil...

After some experimentation I've realised you're quite right.
I was sure I had seen design time data ending up in the viewstate at some
stage and I thought this was it's intended behaviour....

Perhaps I was mistaken or it was a problem in the beta's. In any case
you've set me a little straighter on how viewstate works within controls (I
get the feeling I'm not quite there yet as you'll see in another post
following this one).

Thanks once again... you've saved me from writting some rather silly code.

-----Original Message-----
From: Nikhil Kothari [mailto:Click here to reveal e-mail address]
Sent: Sunday, 21 April 2002 3:54 PM
To: aspngcontrolscs
Subject: [aspngcontrolscs] RE: Best practices for minimising ViewState

You do not have to implement any of this.
ViewState is already smart about round-tripping only those values that have
been changed from their initial state.

The stuff that gets set declaratively on a tag is part of the initial state,
and it doesn't round-trip as part of the data in the hidden field.

Nikhil Kothari
ASP.NET Development

    -----Original Message-----
    From: Michael [mailto:Click here to reveal e-mail address]
    Sent: Sat 4/20/2002 8:04 PM
    To: aspngcontrolscs
    Cc:
    Subject: [aspngcontrolscs] Best practices for minimising ViewState



    Does anyone out there have any tips for how control developers can
generically keep control state whilst keeping the use of ViewState to an
absolute minimum ?
    
    Using ViewState to record a control's settings seems to quickly
become very costly in terms of the page load times/HTML byte sizes. The
documentation seems to suggest that if you have properties or other state
data that can be altered at run time the ViewState should be used to hold
that data. This seems to be a little inefficient as property values set at
design time can end up in the page's ViewState.
    
    Ideally I'd like to only store information in the ViewState when it
has been set at runtime. I can't seem to find a way of easily
differentiating between property changes as a result of design time
assignments and other property changes such as from a postback.
    
    One possible approach is to mark all the properties of the control
with the DesignOnly(true) attribute, and then supply methods (which utilise
the ViewState) for use at runtime, and then in the LoadViewState restore
state data only if it exists:-
    
    object viewStateData = ViewState[viewStateKey];
    if (viewStateData != null)
     myDataMember = (ADataType)viewStateData;
    

    It will work but having two points access for every setting of the
control seems a little costly in terms of code maintainability.
    
    Another approach is by default to disable the use of ViewState and
then supply flags to enable ViewState individually for each property:-
    
    public string MyProperty { ..... }
    public bool MyPropertyEnableViewState { ..... }
    
    This approach seems like a bit more of a kludge.
    
    What do you think of either of these approaches ?
    Can anyone out there think of a better approach ?
    
    Michael Lang
    MS .NET Developer
    Ph: +61 0417-498-620
    www.michaellang.com.au <http://www.michaellang.com.au/>
    
    | [aspngcontrolscs] member Click here to reveal e-mail address = YOUR ID |
http://www.asplists.com/asplists/aspngcontrolscs.asp = JOIN/QUIT |
http://www.asplists.com/search = SEARCH Archives < /BLOCKQUOTE >

j??zf?i    rVj9?rr
Reply to this message...
 
 




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com