Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
During recent few engagements with my customers I've noticed VIewState is extensively [unintentionally] used. ViewState is on by default. The result is heavy weight Html that round trips on the network. This causes slow response time and high network utilization that affects another applications using the same network.
How to remove ViewState from the network completely while taking an advantage if its functionality at same time?
This post walks through basic steps of creating ASP.NET Base Page that implements functionality allowing saving ViewState on the server. The approach reduces dramatically network utilization.
Summary of steps
The following section describes each step in details.
class LeaveViewStateOnTheServer : Page
protected override object LoadPageStateFromPersistenceMedium()
string m_viewState = (string)Session["ViewState"];
LosFormatter m_formatter = new LosFormatter();
viewStateBag = m_formatter.Deserialize(m_viewState);
throw new HttpException("The View State is invalid.");
protected override void SavePageStateToPersistenceMedium(object viewState)
MemoryStream ms = new MemoryStream();
LosFormatter m_formatter = new LosFormatter();
ms.Position = 0;
StreamReader sr = new StreamReader(ms);
string viewStateString = sr.ReadToEnd();
Session["ViewState"] = viewStateString;
public partial class _Default : LeaveViewStateOnTheServer
And here is how it looks without:
My Related Posts
Download Sample Visual Studio 2008 solution from my SkyDrive:
What about if your customer uses more than one page in the same session? I think he won't be happy...
Dude, WAY Simplier
protected override PageStatePersister PageStatePersister
return new SessionPageStatePersister(Page);
saving viewstatesss to session? unless you are kidding me this is not for real world web applications.
@shuj - Good question! Dino has an aswer.
How should you choose the name of the file to ensure that no conflicts arise? The view state is specific to a page request made within a particular session. So the session ID and the request URL are unique pieces of information that can be used to associate the request with the right file. Alternatively, you could give the view state file a randomly generated name and persist the file name in a custom hidden field within the page
@Russ - I am not sure i get this.I need to do my H/W here. Thanks for the code.
@kazlak - I think I know what you mean. I saw cases where session was not the option i saw also cases where it perfectly was. Both were very real to me :). Any way the sample demonstrate overrideing Page's ViewState relevant methods - way too many developers are not aware of it. The rest is up to your imagination - save it to Session, DB, files, even Cache [i did that too - we had our reasons for that - very real world reasons]. Yesterday i was at customer's where we implemented it and explained implications of using session for saving ViewSate. He understood and accepted the risks. All is happy. What are the risks of using Session from your stand?
Sorry, should have included....
And, again because I can't put two thoughts into the same submission....
The code that Dino goes into is great, we used a version of it for a while, but did run into problems when session would time out with out implimentation.
What Dino's code also gives you is the ability to deploy this with all versions of .NET, where the SessionPageStatePersister is new to 2.0
alik am sure you understand the risks already, am more interested now to know scalable is the application you are referring to. things like how many concurrent users are you talking about? what is the server architecture that this application can be deployed to?.. etc
@Russ - be sure you got me hooked on this new feature and i am definitely going to do my H/W :) – thanks. BTW – w/r to session expiration, I hit the same problem once. This was the case where we decided to put into Cache – it is independent from Session and then we set proper expiration timeout.
@kazlak – totally agree and I even – it is less scalable approach. I hate the fact I did not state it in first place – good catch! Imagine the situation where the application cannot breath…. Because of ViewSate of 400-600 Kb. It is in production and your end users are really mad at you. What would you prefer to make it breath or make the “right” architecture. Things like that. It depends where you at with the project – inception phase or fire alarm in production. That is why I am a big fun of PDL – performance development lifecycle. Doing right things during all dev stages. And not waiting for a fire alarm when in production
This is a follow up post to Basic Sample - How To Keep ASP.NET ViewState On The Server ASP.NET 2.0 offers