为什么ViewState默认不存储在服务器上？

Question

默认情况下有人能给我一个很好的理由说明ViewState没有存储在服务器上吗？

为什么不发送一个小会话令牌来代替ViewState，然后可以将其映射到服务器上需要的任何ViewState信息，以防止整个ViewState被多次回发和转发。

我错过了什么吗？

Answer 1

可伸缩性 - 想象一下，如果1M用户查看复杂的WebForms页面，将需要多少服务器资源。服务器至少需要在会话超时期间保持ViewState。 viewstate的自动服务器端清理也会有问题 - 用户可能会同时查看多个页面，因此需要保留所有页面的ViewState。

修改 these posts中讨论了有关如何将viewstate移动到服务器的几种技术。但是，在您这样做之前，最好从不需要它的控件/页面中删除不必要的视图状态（例如，仅查看/不回发渲染）。

我现在在猜测，但是当viewstate在大约10年前设计时，32位服务器上的1GB RAM大约和它一样好，而MS可能不得不考虑托管服务提供商需要加载100个应用程序服务器。因此，带宽可能被视为比服务器Ram和磁盘存储更便宜。

Answer 2

将ViewState存储在内存中存在许多问题。

1. 如果应用程序回收，则使用该应用程序的所有人的VS都将丢失。

2. 它增加了应用程序的内存消耗。如果服务器上只托管了几个应用程序，这不是问题;但有些情况下可能会在一个盒子上托管许多网站。

3. 可扩展性;应用程序越活跃，VS需要存储的越多。你不能假设1-1（1个用户 - 1个VS）。用户可以打开多个标签，可以返回，保持标签处于非活动状态等...这导致：

4. 你存放VS多久了？保持页面上编码的数据可确保在用户离开网站一段时间后仍然存在。

5. 如果您托管在网络服务器场上会发生什么。我们无法保证用户在每次请求时都会使用同一台计算机。

话虽如此，有一些解决方案：

Memcached-Viewstate - 使用Memcache将VS存储在分布式内存中。这并不理想 - 如果服务器因为存储在该服务器上的VS丢失的任何人而导致VS关闭，但是会允许应用程序池重置而不会出现问题。

SQL-Viewstate - 将VS存储在SQL数据库中。这为每个请求添加了至少1个DB读取和1个DB写入。再次，不理想，但如果VS变得无法管理，从数据库中设置VS比通过HTTP发送和接收VS更快。

Filesystem-Viewstate - 将VS存储在文件系统中。它比SQL连接便宜，但需要文件服务器才能在分布式环境中工作。

Answer 3

它提高了可伸缩性，因为服务器不需要在内存中维护所有这些内容。可以将viewstate存储在会话中，但通常不建议这样做。

Answer 4

根本原因是使用客户端视图状态是服务器不知道页面的当前状态。

如果用户感到焦虑，在页面上进行多次（部分）回发，而不等待响应，浏览器将发出多个部分回发请求，每个请求在服务器端创建一个新的视图状态，最终将被清除浏览器中的初始视图状态。最后，用户进行了他的最后一次回发，那时，初始副本消失了，因此抛出了异常。

服务器端视图状态也会影响服务器性能和用户体验。如果用户在一天或很长时间内未与页面交互，则服务器上的视图状态将过期。当用户稍后回发页面时，会抛出异常。

例如，我观看长度为40分钟的youtube视频。昨天我看了上半场，没有关闭标签但是对我的电脑进行了骚扰。今天我继续观察下半部分，并发回一些内容，如果视图状态在服务器中并且已过期，页面将会出错。