Comments on: How I Learned to Stop Worrying and Love the View State

By: urkurk

urkurk — Mon, 04 Jan 2010 09:05:21 +0000

hi tatham

i tried loading the treeview data only when it isn’t a page postback and the duplication was fixed

is this the right way to do it?

By: urkurk

urkurk — Mon, 04 Jan 2010 08:58:31 +0000

hi tatham,

thank u for this article…

however when i tried placing my code to populate a treeview inside the page init event the items added were duplicated for each page postback.

can you pls. explain why this is happening and what is the proper way to fix it?

thanks.

By: Knowledgebase » Blog Archive » How disabling viewstate on ASP .NET 2.0 website effects you’re code

Tue, 29 Dec 2009 09:18:50 +0000

[...] on viewstate, read: http://blog.tatham.oddie.com.au/2008/12/18/how-i-learned-to-stop-worrying-and-love-the-view-state/ Share and [...]

By: Reading for the day « dotnet etc.

Reading for the day « dotnet etc. — Wed, 04 Feb 2009 17:41:34 +0000

[...] a comment » I want to share 2 links here: 1) Top 25 dangerous programming practices 2) How I Learned to Stop Worrying and Love the View State 3) Why does projects/leadership failes? Possibly related posts: (automatically generated)Deferred: [...]

By: Tatham Oddie

Tatham Oddie — Thu, 25 Dec 2008 12:15:15 +0000

Hi Tom,

Thanks for your comment!

I definitely agree with you that the applications with the best opportunity to scale are those that do not require server-side statefulness. View state is a great tool for involving the client in this process.

That being said, loading a list of countries (which was my example) is by no means an expansive exercise. It also places no requirement on server side state if we are to remove this from the view state – it’s the same list of countries irrespective of who is loading the page.

If it was an expensive list to load, we could cache this in the HttpContext.Current.Cache property which is shared between sessions and thus would not affect our capacity to scale.

If we needed to filter the list of countries in a way that was session-specific, such as only showing countries within a specific region, all we need to do is store the region in the view state. The process of evaluating which countries are in that region and loading them into the control can still be completed in the Init event. This keeps our view state small and scalability high at the same time.

Do you agree with all that?

- Tatham

By: Tom Pester

Tom Pester — Sat, 20 Dec 2008 16:01:48 +0000

Although I agree that an asp.net developer has to keep an eye on the viewstate the pattern you describe of binding the result of an expensive call to the database in the pageload event is actualy intended. I don’t want to speak for the architects that made asp.net but their intention was that to make scalable web applications the client got involved in maintaining state.
If you aim for high performant websites that scale it is actualy beneficial to store results on the client (within reason!) so that the server can get all the info it needs of the browser request and doesn’t need to query the database in successive calls.
If viewstate becomes too big than your have the solution in your post if you put the database result in the cache. But if the information is to be scope to the user and not the whole application it *can* become less scalable if the info was stored in a session variale on the server (1000 users = 1000 * size of the session).
After reading a few books on wcf and conurrent systems I learned that the server is busy with only a small percentage of its users at any give time (I dont know the exact and it depents on the situation but the percentage but its surprisingly low).
If the server can “forget” everything after a request can be handled its througput can be increases. Using the client as a database (viewstate) makes it possible for the server to handle each next request “in memory” and he does not have to remember a thing for the client.

By: Tatham Oddie

Tatham Oddie — Sat, 20 Dec 2008 09:05:41 +0000

Hi Josh,

In this case I was using a standard DropDownList control as an example.

I discuss separating things into custom controls in my next post:

http://blog.tatham.oddie.com.au/2008/12/20/accessing-aspnet-page-controls-during-preinit/

I broke it out separately because:

a) not everything can be subclassed (or is worth it)
b) to subclass it, you need to be aware of an intricacy with the PreInit event which I felt went beyond the scope of this post.

Thanks for the great comment!

- Tatham

By: Accessing ASP.NET Page Controls During PreInit « Enter the Tatrix

Accessing ASP.NET Page Controls During PreInit « Enter the Tatrix — Fri, 19 Dec 2008 20:33:12 +0000

[...] a comment » If you’ve read my previous post explaining a common pitfall with view state, I’d hope you’re preparing all your controls in the Init event of the page/control [...]

By: Josh Rivers

Josh Rivers — Fri, 19 Dec 2008 18:33:01 +0000

Should the code go into the Control’s init handler rather than the page’s? That might provide for better separation.

By: Tatham Oddie

Tatham Oddie — Thu, 18 Dec 2008 21:27:54 +0000

Hi Andy,

Thanks for your response.

If the list of countries is expensive to retreive, although common across different users, then we should be storing it on the servers cache. This way we can keep our view state small as well as improving performance for _all_ users on the site.

Re: EnableViewState. If we populate the control at the correct stage of the lifecycle, we do not need to fallback to setting this property. Filling a control from the Load event, wrapping it in an IsPostBack check and setting EnableViewState to false sounds like a lot more hacking than just moving the population code to the Init event.

- Tatham