I am reading the article: Nine Options for Managing Persistent User State in Your ASP.NET Application by Steven A. Smith (Doesn't he host a show on ESPN?)
In the article, Steven makes the following statement: "When dealing with a single ASP.NET page, ViewState is a better choice than QueryString for maintaining state"
Unfortunately, he does not explain why that is so. Why is this so?
I would imagine because the QueryString is part of the URI of the page - and thus can be tampered with by the user. Not to mention there's a limited amount of space in the QueryString - limited to the maximum size of a URL (2048 bytes in IE, other browsers are more accommodating).
Aside from tampering, storing random bits of state in the QueryString would lead to very ugly URLs - and therefore URLs that are unfriendly to search engines.
Erik is correct, but I would also add that in ASP.NET the ViewState is serialized into a hidden form element for you. The idea is that you could store anything in the ViewState (even complex objects), and they'll be serialized automagically, whereas storing such objects in the QueryString usually means deconstructing them manually and writing some sort of parser to re-build them.
It isn't.
ViewState is stored within the page itself, in a hidden form field. That's useful, in scenarios where the state is effectively transient - WebForms relies on it by default for control state - but the only way for it to actually persist across page loads is by forcing a postback each time a request is made to the server.
The query string is part of the URL - changing the query string changes the URL. Requesting a URL where page state is stored in the URL will preserve that state. Therefore, there is potential to preserve state even across sessions or between users - a URL can be bookmarked and requested again later, sent via email, etc. Of course, this state is attached to a single page, as part of a single URL - if it is needed by another page, it must be transferred manually (by appending a query string for that page) or via some other means (cookies, POST data, server-side session data). And of course, if you don't want to preserve state across time and space... or your state is very large... query strings are not appropriate.
Note that logically, both ViewState and state stored in query strings are page-specific; although they can be forewarded to another page as part of a GET (query string) or POST request (ViewState), the browser will not by itself associate them with requests to separate pages, nor will it update these states when returning to a previous page. The small amount of extra security afforded to ViewState (as Erik notes) - may be why Mr. Smith recommends it for storing user-specific state on a single page. However, hacks to make them work cross-page aside, this per-page attachment generally makes cookies (or server-side session state indexed by a client-side cookie) more appropriate for holding state that is specific to a given user or session but not specific to any single page.
Personally, i've never found ViewState particularly useful - it's fragile and places severe restrictions on how navigation can be performed. However, if you're sticking to a pure WebForms postback/redirect model, it can be made to work effectively (as the framework will handle most of the ugly details for you). Be aware that trying to do too much on a single page can lead to very large amounts of ViewState and correspondingly slow load/reload times for your users.
I noticed that you've included ASP.NET MVC in your tags for this question. You should be aware that ASP.NET MVC does not have ViewState. At all.
It all depends.
Items in your QueryString can be deep linked. You might not want that or might need to code around that.
QueryString is limited in length. Not that someone should put 10K in their viewstate but I have put more than the 2k limit* on a QueryString in ViewState on occation when needed. Not somehting that you can do at all with a QyeryString.
In most cases, you should be using a combination of both. With MVC, you loose ViewState but will likely develope your own similar solution in some cases.
EDIT: * Different browsers support different max lengths but still an issue. http://www.aspfaq.com/show.asp?id=2222