将存储在 Viewstate 中的 DataTable 转换为 List<T> 是一个不好的选择吗？

Question

我刚刚开始了一份新工作，并继承了一个噩梦般的 WebForms .net 4.0 项目，该项目在很多地方都出错了。

我有一个在 ViewState 中存储 DataTable 的用户控件。该代码通过索引号引用整个代码中的列，这使得它完全不可读。我知道我可以按名称引用列以使其更具可读性，但我更愿意将其分解为一个列表。

之前的开发者将列表存储在 ViewState 中，因为更改无法持久化回数据库，我们读入数据，销售人员可以对定价进行修改，然后将信息推送到 XML 格式以生成销售PDF 格式的订购单。所以我们需要一个临时存储的机制。

如果我有从头开始的奢侈，我会在 JSON 中提取数据并在客户端完成所有操作，但我还没有这种奢侈。

1. 自从我使用 DataTables 已经很久很久了 很确定把它放在 ViewState 中不好，是吗？ 正确的？它会给 ViewState 带来什么样的负载； 我们正在查看 44 列，通常大约 25 行。 :s

2. 其次，如果将 List 放入 ViewState 而不是 DataTable 或者它们都一样糟糕 其他 - 在这种情况下，我不会伤害我目前的职位 换掉？

3. 第三个问题，对行的更新会在 ViewState DataTable，和List一样吗？

4. 最后一个，更多探索建议。最好的地方在哪里 存储此信息（最好是列表）服务器端 - 将 Session 还是 Cache 更好？

Answer 1

1. 你是对的。将 DataTable 存储在 ViewState 中是一个糟糕的主意。

2. 在 ViewState 中存储列表仍然很糟糕，并且可能比存储 DataTable 略好。

3. 不清楚您所说的“更新在 DataTable 上自动发生”是什么意思。除非您从 ViewState 检索 DataTable 并以编程方式应用任何更新，否则我怀疑情况是否如此。如果你使用 List，你也必须这样做。

4. Session 可能更好，但您可能会遇到可伸缩性问题。坦率地说，我会将其存储在 Session 中，但会选择使用 Out of Proc 状态提供程序之一。这样，您的序列化数据表不会在每次请求时都发送到客户端，从而使您的页面大小非常大，同时让您可以选择将此序列化数据存储在不同的位置，例如 SQL 服务器或 ASP.NET 状态服务器。