非常大的视图状态破坏网络应用程序答案

【问题标题】：very large viewstate breaking web app非常大的视图状态破坏网络应用程序
【发布时间】：2011-04-04 08:39:18
【问题描述】：

我有一个使用网络服务的网络应用程序。主页运行搜索 - 通过将参数传递给特定的 Web 服务方法，然后我将结果绑定到 gridview。

我已经在网格上实现了排序和分页。通过将网格绑定到的数据表放入视图状态，然后根据需要读取/排序/过滤它 - 并重新绑定到网格。

随着从 Web 服务返回的数据量急剧增加，当我尝试分页/排序等时，我收到以下错误。

连接已重置

在页面加载时重置了与服务器的连接。

我搜索了一下，似乎是一个非常大的视图状态应该为此负责。但肯定唯一的其他选择是

限制结果
在会话中粘贴数据表而不是视图状态
我不知道的其他事情

以前我在会话中确实有数据表，因为其中一些数据需要在页面之间持续存在 - （但是没有发布，所以视图状态不是一个选项）。随着数据量的增加和持久化它的必要性被删除，我改用了视图状态。认为这是比会话更好的选择，因为会话必须保存的数据量以及使用该应用的用户数量。

看起来可能不是。

我认为当视图状态变得非常大时，.net 会将其拆分为多个隐藏视图状态字段，但似乎我得到的只是一个庞大的视图状态，我无法在源代码中查看。

谁能告诉我如何避免我遇到的错误？如果确实和viewstate中的数据量有关？

【问题讨论】：

标签： asp.net sorting pagination viewstate

【解决方案1】：

这听起来像是您为所有页面缓存整个数据集，即使您只显示该数据的一页。我会将您的分页更改为仅需要用户当前页面的数据。

如果查询很繁重，并且您不想因为有很多来回分页而不断地反复调用它（您应该测试典型的使用模式），那么我将实现某种类型的缓存在网络服务端逐页缓存（如果数据是特定于用户的，则由特定用户缓存）并让它很快过期（例如几分钟）。

我认为您需要限制处理的数据总量。更改您的代码以不传回可能永远不需要的额外数据是一个不错的起点。

编辑：根据您的 cmets：

您无法更改网络服务
用户可以通过过滤或排序来操作查询
网络服务返回大量数据
数据是用户特定的

我认为你有一个完美的案例来使用Session。这可能会对拥有大量用户和数据的服务器造成负担，因此您可能需要实施一些逻辑来清除 Session 中的数据，而不是等待它过期（例如在某些登录页面上，您知道用户会离开完成后，清除会话数据）。

你真的想把它从ViewState 中取出来，因为它占用了大量的带宽。只需查看您的物理页面大小，每个操作都会来回传递数据。将其移至 Session 将消除带宽使用并允许您做任何您需要的事情。

您还可以查看 Web 服务返回的数据，并将其存储在您尽可能“精简”的自定义对象中。如果您在Session 中存储DataSet 或DataTable，则这些对象有一些额外的开销，您可能不需要因此将数据存储为一些自定义瘦对象的数组并绑定到该数组。您需要将 WS 的结果映射到您的自定义对象，但这是减少内存使用的好选择。

如果我还缺少其他东西，请告诉我。

【讨论】：

嗨，感谢您的回复，为了做到这一点，WS 必须接受排序/页面参数。基本上在 WS 端处理分页/排序，并在时间。但为了做到这一点，您必须像您所说的那样为每个登录的用户保留一个唯一的主搜索（我们确实有一个随每个 WS 请求传递的会话 id）并通过它进行排序和分页。可悲的是，这永远不会发生。 WS 几乎是一成不变的。所以必须处理我所拥有的......在下一条评论中继续
继续.. 客户端需要返回所有数据，以便他们可以找到他们想要的内容。有一个限制参数传递给初始大型搜索，但设置太低可能无法找到他们正在寻找的记录..因为它可能不会从 WS 的记录集中返回任何其他想法？
再次感谢，您的观点是正确的，我已切换回会话，一切都很好。以前只是因为在视图状态上使用会话而被大便。当然我认为视图状态很好，就好像他们将搜索页面放在那里一样，他们可以在 2 小时内返回并仍然对其进行过滤/排序（如果viewstate wast too big ofc) 会话（如果我不希望服务器停止运行）将在不到 2 小时的时间内放弃他们的会话。再次感谢 nat

【解决方案2】：

我不会将数据置于视图状态或会话中。而是存储最低限度的信息以从 Web 服务重新请求数据集并将其存储（在视图状态或会话中，甚至在 URL 上）。然后使用该数据调用 Web 服务并对每个请求的数据作出反应。如有必要，请考虑使用某种形式的缓存 (memCache) 来提高性能。

【讨论】：