Wean Yourselves off View State From the Start
Posted in Development
Whenever I start a new project these days, I head straight to web.config and do this:
<pages enableViewState="false" enableSessionState="false" autoEventWireup="false">
The key here is the first attribute. If you knock out view state right from the start, I can guarantee you will approach your site differently.
You won’t be tempted to drag and drop DataGrids, which are view state hogs because they depend on it for paging and sorting. To me, the DataGrid control is the ultimate insult to aesthetics.
You won’t be tempted to stuff junk if view state simply because it’s a seemingly convenient practice.
You won’t be tempted to use autopostback with dropdowns and such.
You will do a lot of things differently without view state. Try it.
14 comments
Scott Muc
on July 10, 2009
What are the ramifications of autoEventWireup="false"?
Does that mean that void Page_Load(object sender, EventArgs e) needs to be in an overriden OnInit(EventArgs e) method?
Jatinder Singh
on July 10, 2009
AutoEventWireUp is used to associate OnLoad to Page_Load automatically. By default at machine.config the attribute is true. What this really means is you need to write the override code for Page_load and Page_Init ; in case it is false else it is done automatically.
Hope it Helps
Jatinder Singh
Milan Negovan
on July 10, 2009
Great clarification, Jatinder.
I have a strong dislike for methods with magic names such as Page_Load. Please take a look at this article of mine. I prefer to be expressive which virtual methods I want to override. Besides, I don't want to pay the price of discovering those magic methods via reflection.
Speednet
on July 11, 2009
You folks mentioning autoEventWireup="false" and Page_Load: this is an area that VB is better than C#. (Not sure if the new version of C# still lacks the feature.)
In VB, you can turn off autoEventWireup and use the Handles clause on a method to wire it to the event. It has many benefits: it does not rely on "magic name" and reflection, you are not reliant upon the autoEventWireups, and it is superior in terms of clear coding techniques. (Self-documenting.)
Damien
on July 15, 2009
Why disable Sessionstate?
This might seem like a stupid question... but then how do you track sessions?
Milan Negovan
on July 15, 2009
So you wouldn't be tempted to abuse the session state. :) Burn that bridge.
Btw, not a stupid question at all.
Damien
on July 15, 2009
Hmmm... I now feel like I'm being "upsold". I found this page whilst googling for a solution to a recently surfacing viewstate error - and am even considering turning it off to "see what happens" (I'm racking my brains to think, did I actually use viewstate anywhere??).
A world without viewstate is potentially attactive... but a world without sessions?? That's too rich for me!! :-)
Milan Negovan
on July 15, 2009
LOL! This post is "three for the price of one." What was your view state error all about?
Damien
on July 15, 2009
> What was your view state error all about?
I'm not sure yet... :-(
The site is kind of 'like' a banking site - is, SSL, large number of pages, users log in etc. I'm not sure if it makes a difference, but there's quite a large "data access layer" DLL behind the site that drives the business logic. Each session is 'non trivial' with regards to increased session load.
The site's been live for about 8 months, receiving between 80 - 120 visits per day. Last week, some marketing went out via an email blast, which spiked usage up to 800 visits per day. In that time, I've received two viewstate errors, similar to below.
I'm wondering if the increased load is causing the application pool to recycle (see http://support.microsoft.com/kb/555353) more frequently and hence this issue to present.
The site's running on Framework 3.5 - I have a small (but manageable) addiction to Linq!! ;-)
Error Thrown from IP 128.250.5.247.
System.Web.UI.ViewStateException: Invalid viewstate.
Client IP: 128.250.5.247
Port: 50613
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
ViewState: /wEWBQLU2r2ICALixKoUAtvJ3a8CAubk9ZIIAvbHi9AIStEdbkOBWg4wFYwsBjv1apx+h2s=
Referer: https://secure.....
Milan Negovan
on July 15, 2009
I see. This is one very elusive error because there are sooo many things that can go wrong.
It has bitten me with dynamic controls before.
It also happened to me numerous times when visitors came through proxies which maimed the view state string.
If your site runs in a web farm, make sure the machineKey section in web.config is the same.
Etc, etc.
I'm willing to bet that your DAL has little to do with this.
Damien
on July 15, 2009
Thanks Milan.
> happened to me ...when visitors came through proxies
Hmmm - I hadn't thought of that! I assume that there's nothing that can be done about it short of disabling viewstate?
Milan Negovan
on July 15, 2009
Normally, I don't worry about those.
In my case, more often than not someone is trying to hack my view state string sitting behind an anonymous proxy. Even when that's not the case, there's nothing I can do about those proxies anyway.
An if view state is disabled altogether, who cares? :)
Damien
on July 15, 2009
Thanks Milan.
I'm going to turn off viewstate in the dev envionment (but not sessionstate!!) and see what breaks :-)
Martin S.
on July 10, 2009
Cannot agree more! This is your best friend if you want a quality web app.
Rock on, man!