Can server-side viewstates fix one of the biggest problems with ASP.NET?

Question

Hi,

I've read a few SO articles about whether or not ASP.NET MVC is worth the migration from "regular" ASP.NET. One of the biggest reasons for using MVC I've seen quoted was not having to use Viewstates.

However, it is possible to eliminate viewstates by storing the viewstate information on the server as this article shows. I've tried it in a sample project, it works great, is fully transparent as far as I noticed it and was very easy to implement.

So, where's the catch? I expect it does put a slightly higher load on the server, but can it really be that bad? If not, why aren't more people using this approach instead of complaining about viewstates?

Answer 1

The larger your project gets and/or the more people you potentially have using it, that miniscule effect on your performance can become pretty massive.

Answer 2

The only issue with viewstate is abusing the use of it. This easily happens as the default is to have it all on. You can't even turn it all off by default on a page, and selectively turn on specific controls (they will add support for this on the 4.0). You will see few code with the viewstate=false on it, and with lists of info it can get big fast.

There are even some third party controls that abuse it awfully. I had to help finding out why a page was awfully slow (as in it doesn't even works), and it turned out the amount of info downloaded was huge, the cause was the viewstate was 10+ times the size of the content (really) and it was a third party control that liked storing everything you handed to it (which got really ugly because it was handed a hierarchy of objects).

So the real problem isn't the viewstate, it is its size. If you already have the problem of big viewstates (normal big, not the extreme of the above), then moving it to session on the server means you will be storing a huge amount of info. This is moving the problem from one place to other, perhaps mitigating some of its effects, but it doesn't address the real issue, storing too much unneeded state (because either the developers did or some third party stuff misbehaved).

That said, I don't think I would call it the single main problem with the regular asp.net approach. Don't take this as a "don't develop with it", but more like a "if you will develop on it, get to know it really well". I work a lot with regular asp.net, it Can work and very well. If I were to begin on it at this point, I think I would go with asp.net mvc though, as I think regular asp.net needs a whole lot more from the developer to get it right.

Answer 3

To be honest, most of the time you can trim the viewstate right down - alot of developers, me included, dont go through all controls that dont need it and disable it - I tend to find that I only need viewstates for stuff like datagrids, most other controls tend to work fine, but as I said, I dont do it as often as I should.

Answer 4

I tend not to agree with the statement that moving to ASP.NET MVC is all about removing viewstate. The use or otherwise of ViewState is a minor concern when it comes to deciding whether to move to ASP.NET MVC. More important is the seperation you get between your model (the types that define your problem area) your controllers (the code that describes how users interact with your site) and your views (the rendering logic that generates HTML or whatever other markup you like).

With regard to putting viewstate into your server, this could well become a scalability bottle neck - if you had a multi webserver site then you'd need to be able to access that viewstate from all of those servers. You then need to worry about clearing that viewstate out - when it's embedded in the page there's nothing to consider, but if it's stored on the server then how long should a page's viewstate be kept?

Basically, the reason that viewstate exists is to support the "web forms" approach to web development, where a page posts back to the server in order to update itself. It's this approach to web development, rather than viewstate itself, that I think most people want to avoid. Stateless markup, plus AJAX updates where required, makes for a much cleaner application and one where things like output caching can be applied much more readily.