我已经阅读了一些关于 ASP.NET MVC 是否值得从“常规”ASP.NET 迁移的 SO 文章。我看到引用的使用 MVC 的最大原因之一是不必使用 Viewstates。
但是，可以通过在服务器上存储视图状态信息来消除视图状态，如本文所示。我已经在一个示例项目中尝试过它，它工作得很好，就我注意到它而言是完全透明的，并且很容易实现。
那么，问题在哪里？我希望它确实会给服务器带来稍高的负载，但它真的会那么糟糕吗？如果没有，为什么没有更多的人使用这种方法而不是抱怨视图状态？
Adrian Grigore
问问题
227 次
4 回答
2
viewstate 的唯一问题是滥用它。这很容易发生，因为默认设置是全部打开。您甚至不能在页面上默认将其全部关闭，并有选择地打开特定控件（他们将在 4.0 上添加对此的支持）。你会看到一些带有 viewstate=false 的代码，并且使用信息列表可以快速变大。
甚至还有一些第三方控件严重滥用它。我不得不帮助找出为什么页面非常慢（因为它甚至无法正常工作），结果下载的信息量很大，原因是视图状态是内容大小的 10 倍以上（真的）并且它是一个第三方控件，喜欢存储你交给它的所有东西（它变得非常丑陋，因为它被交给了一个对象层次结构）。
所以真正的问题不是视图状态，而是它的大小。如果您已经遇到大视图状态的问题（正常大，而不是上述极端情况），那么将其移动到服务器上的会话意味着您将存储大量信息。这将问题从一个地方转移到另一个地方，也许减轻了它的一些影响，但它并没有解决真正的问题，存储了太多不需要的状态（因为要么是开发人员做了，要么是一些第三方的东西行为不端）。
也就是说，我认为我不会将其称为常规 asp.net 方法的单一主要问题。不要把它当成“不要用它来开发”，而更像是“如果你会在它上面开发，就去真正了解它”。我经常使用常规的 asp.net，它可以工作并且非常好。如果我从这个时候开始，我想我会选择 asp.net mvc，因为我认为常规的 asp.net 需要开发人员提供更多的东西才能让它正确。
于 2009-03-12T20:29:17.177 回答
1
我倾向于不同意迁移到 ASP.NET MVC 就是移除视图状态的说法。在决定是否迁移到 ASP.NET MVC 时，是否使用 ViewState 是一个次要问题。更重要的是您在模型（定义问题区域的类型）和控制器（描述用户如何与您的站点交互的代码）和视图（生成 HTML 或您喜欢的任何其他标记的呈现逻辑）之间获得的分离.
关于将视图状态放入您的服务器，这很可能成为可伸缩性瓶颈 - 如果您有一个多 Web 服务器站点，那么您需要能够从所有这些服务器访问该视图状态。然后您需要担心清除该视图状态 - 当它嵌入到页面中时，没有什么需要考虑的，但是如果它存储在服务器上，那么页面的视图状态应该保留多长时间？
基本上，viewstate 存在的原因是为了支持 Web 开发的“Web 表单”方法，其中页面回发到服务器以更新自身。我认为大多数人想要避免的是这种 Web 开发方法，而不是 viewstate 本身。无状态标记，加上需要的 AJAX 更新，使得应用程序更加简洁，并且可以更轻松地应用输出缓存等内容。
于 2009-03-15T21:58:33.843 回答
0
你的项目越大和/或你可能使用它的人越多，对你的表现的微小影响就会变得相当大。
于 2009-03-12T20:21:11.300 回答
0
老实说，大多数时候你可以直接修剪视图状态——包括我在内的很多开发人员，不要遍历所有不需要它的控件并禁用它——我倾向于发现我只需要像数据网格这样的东西的视图状态，大多数其他控件往往工作正常，但正如我所说，我不经常这样做。
于 2009-03-12T20:33:22.067 回答