服务器端视图状态能否解决 ASP.NET 的最大问题之一？答案

【问题标题】：Can server-side viewstates fix one of the biggest problems with ASP.NET?服务器端视图状态能否解决 ASP.NET 的最大问题之一？
【发布时间】：2009-03-12 20:18:51
【问题描述】：

我已经阅读了一些关于 ASP.NET MVC 是否值得从“常规”ASP.NET 迁移的 SO 文章。我看到引用的使用 MVC 的最大原因之一是不必使用 Viewstates。

但是，可以通过在服务器上存储视图状态信息来消除视图状态，如this article 所示。我已经在一个示例项目中尝试过，效果很好，就我所注意到的而言是完全透明的，并且很容易实现。

那么，问题在哪里？我希望它确实会给服务器带来稍高的负载，但它真的会那么糟糕吗？如果没有，为什么没有更多的人使用这种方法而不是抱怨视图状态？

【问题讨论】：

我猜他们只是不熟悉它。

标签： asp.net viewstate

【解决方案1】：

viewstate 的唯一问题是滥用它。这很容易发生，因为默认设置是全部打开。您甚至不能在页面上默认将其全部关闭，并有选择地打开特定控件（他们将在 4.0 上添加对此的支持）。你会看到一些带有 viewstate=false 的代码，并且使用信息列表可以快速变大。

甚至还有一些第三方控件严重滥用它。我不得不帮助找出为什么页面非常慢（因为它甚至不起作用），结果下载的信息量很大，原因是视图状态是内容大小的 10+ 倍（真的）而且它是一个第三方控件，喜欢存储你交给它的所有东西（它变得非常丑陋，因为它被交给了一个对象层次结构）。

所以真正的问题不是视图状态，而是它的大小。如果您已经遇到大视图状态的问题（正常大，而不是上述的极端），那么将其移动到服务器上的会话意味着您将存储大量信息。这将问题从一个地方转移到另一个地方，也许会减轻它的一些影响，但它并没有解决真正的问题，存储了太多不需要的状态（因为要么是开发人员做了，要么是一些第三方的东西行为不端）。

也就是说，我认为我不会将其称为常规 asp.net 方法的主要问题。不要把这当成“不要用它来开发”，而更像是“如果你会在它上面开发，就去真正了解它”。我经常使用常规的 asp.net，它可以工作并且非常好。如果我从这个时候开始，我想我会选择 asp.net mvc，因为我认为常规的 asp.net 需要开发人员提供更多的东西才能让它正确。

【讨论】：

你的答案第一段恐怕我看不懂，第二、第三段我就不明白了。我问的是 ASP.NET，而不是 MVC。
@Adrian 我更新了整个答案，正如你所说，我最初确实回答了其他问题（当我第一次阅读问题时可能很累，或者我的想法是其他问题:()

【解决方案2】：

我倾向于不同意迁移到 ASP.NET MVC 就是为了移除视图状态的说法。在决定是否迁移到 ASP.NET MVC 时，是否使用 ViewState 是一个次要问题。更重要的是您在模型（定义问题区域的类型）您的控制器（描述用户如何与您的站点交互的代码）和您的视图（生成 HTML 或您喜欢的任何其他标记的呈现逻辑）之间的分离.

关于将视图状态放入您的服务器，这很可能成为可扩展性瓶颈 - 如果您有一个多 Web 服务器站点，那么您需要能够从所有这些服务器访问该视图状态。然后您需要担心清除该视图状态 - 当它嵌入到页面中时，无需考虑任何事情，但如果它存储在服务器上，那么页面的视图状态应该保留多长时间？

基本上，viewstate 存在的原因是为了支持 Web 开发的“Web 表单”方法，其中页面回发到服务器以更新自身。我认为大多数人想要避免的是这种 Web 开发方法，而不是视图状态本身。无状态标记，加上需要的 AJAX 更新，使得应用程序更加简洁，并且可以更轻松地应用输出缓存等内容。

【讨论】：

【解决方案3】：

您的项目越大和/或您可能使用的人越多，对您的绩效的微小影响可能会变得相当大。

【讨论】：

当然，但你可以说很多事情，比如 Linq2SQL，甚至是动态页面。问题当然是，与执行整个页面生命周期、每页运行几个 Linq2SQL 查询等相比，这种影响有多大。

【解决方案4】：

说实话，大多数时候你可以直接调整视图状态——包括我在内的很多开发人员，不会检查所有不需要它的控件并禁用它——我倾向于发现我只需要视图状态来处理东西像数据网格一样，大多数其他控件都可以正常工作，但正如我所说，我不会经常这样做。

【讨论】：