我正在阅读这篇文章： Nine Options for Managing Persistent User State in Your ASP.NET Application 作者：Steven A. Smith（他不是在ESPN主持节目吗？）
在文章中，Steven发表以下声明：“在处理单个ASP.NET页面时，ViewState是比QueryString更好的选择，用于维护状态”
不幸的是，他没有解释为什么会这样。为什么会这样？
答案 0 :(得分：12)
我想是因为QueryString是页面URI的一部分 - 因此可以被用户篡改。更不用说QueryString中的空间有限 - 仅限于URL的最大大小（IE中为2048字节，其他浏览器更容易适应）。
除了篡改之外，在QueryString中存储状态的随机位会导致非常丑陋的URL - 因此对搜索引擎不友好的URL。
答案 1 :(得分：4)
不是。
ViewState存储在页面本身的隐藏表单字段中。这在状态实际上是瞬态的情况下很有用 - WebForms默认依赖于控件状态 - 但实际持久跨页面加载的唯一方法是每次请求时强制回发是服务器。
查询字符串是URL的一部分 - 更改查询字符串会更改URL。请求URL中存储页面状态的URL将保留该状态。因此，甚至可以跨会话或在用户之间保留状态 - URL可以被添加书签并稍后再次请求，通过电子邮件发送等。当然，此状态附加到单个页面，作为单个URL的一部分 - 如果另一个页面需要它，则必须手动传输（通过附加该页面的查询字符串）或通过其他方式（cookie，POST数据，服务器端会话数据）。当然，如果你不希望在时间和空间上保持状态......或者你的状态非常大......查询字符串是不合适的。
请注意，逻辑上，查询字符串中存储的ViewState和状态都是特定于页面的;虽然它们可以作为GET（查询字符串）或POST请求（ViewState）的一部分被预先传递到另一个页面，但浏览器本身不会将它们与单独页面的请求相关联，也不会在返回到上一页时更新这些状态。为ViewState提供的少量额外安全性（如Erik notes） - 可能是史密斯先生建议在单页面上存储用户特定状态的原因。但是，为了使它们跨页面工作，这种每页附件通常使得cookie（或由客户端cookie索引的服务器端会话状态）更适合于保持特定于给定用户或会话的状态但是并非特定于任何单一页面。
就个人而言，我从未发现ViewState特别有用 - 它很脆弱，并且对如何执行导航设置了严格的限制。但是，如果您坚持使用纯WebForms回发/重定向模型，则可以使其有效工作（因为框架将为您处理大部分丑陋的细节）。请注意，尝试在单个页面上执行过多操作可能会导致非常大量的ViewState，并相应地减慢用户的加载/重新加载时间。
答案 2 :(得分：4)
我注意到你已经在这个问题的标签中加入了ASP.NET MVC。您应该知道 ASP.NET MVC没有ViewState。根本没有。
答案 3 :(得分：1)
Erik是正确的，但我还要在ASP.NET中将ViewState序列化为隐藏的表单元素。我们的想法是你可以在ViewState中存储任何东西（甚至是复杂的对象），它们将被自动序列化 ，而在QueryString中存储这些对象通常意味着手动解构它们并编写某种解析器重建它们。
答案 4 :(得分：0)
一切都取决于。
QueryString中的项目可以深层链接。您可能不需要或可能需要围绕它进行编码。
QueryString的长度有限。并不是说有人应该在他们的视图状态中放置10K，但是在需要时我在ViewState中的QueryString上放置了超过2k的限制*。不是说你可以用QyeryString完成任务。
在大多数情况下，您应该使用两者的组合。使用MVC，您可以放松ViewState，但在某些情况下可能会开发出您自己的类似解决方案。
编辑： *不同的浏览器支持不同的最大长度但仍然是个问题。 http://www.aspfaq.com/show.asp?id=2222