【发布时间】：2009-12-10 10:44:44
【问题描述】：
我有一个问题希望有人能回答，将 Datatable 传输到另一个 .aspx 页面以便它可以在 C# 中收集并绑定到 Gridview 的最佳方法是什么？
- Cookie？
- 会话？
- 缓存？
【问题讨论】：
标签： c# asp.net datatable transfer
【发布时间】：2009-12-10 10:44:44
【问题描述】：
没有单一的“最佳” - 因为它取决于应用程序的结构和您要传输的数据块的大小。它还取决于您在两端使用它做什么。
在最基本的层面上，答案是处于会话状态 - cookie 是不合适的，因为（概括）您要移动的数据块太大。缓存的存在是为了避免您不得不重新加载内容，但是（再次概括）您不应该将它用于您需要在您返回查看时需要保留的内容，这会让您有会话。
当然，这假设您完全保留了数据表。另一种方法是只维护允许您从存储中检索数据表的键值 - 因此您为第一页加载表一次，做一些事情，保存键值导航到第二页，从存储中重新加载数据表，然后根据需要进行更新。这在理论上是一个更好的模型（它在开销或将表序列化/反序列化到会话与从数据存储中提取数据之间进行权衡，当然在数据存储和应用程序之间进行权衡是缓存数据的适当机会）如果你沿着这条路线走，你可以使用 session，或者，如果你愿意，可以使用 cookie，这反过来又可以让你摆脱对 session 的依赖。
正如我所说，简单、实用的答案在 Session 中 - 但您需要了解开销以及这对您施加的其他限制。
【讨论】：
-
另一个决定会话和缓存的因素：会话是用户特定的，而缓存是应用程序范围的。所以一个存储在Cache中的item对所有用户都是可见的，而Session却不是这样。
-
@Hans - 我完全错过了这一点，尽管它很明显很疼（好吧，取决于你如何关键的东西）。牢记在心。
Cookies - 绝对不是。 会话 - 可能取决于服务器上的用户数/负载。 缓存 - 可能不是一个好主意，除非许多用户查看同一个网格（即数据保证被缓存）。
您不能向其他页面提供一些信息，以允许该页面获取 gridview 本身的数据 - 可能像查询字符串参数一样简单，例如productId=10?
还可以阅读 ASP.NET 中的 cross page posting。
【讨论】：
如果您执行重定向到其他页面，Session 是一个好地方。但如果 DataTable 重新创建的成本不是太高，我可能会向数据库发送一个新查询。
【讨论】：
Cross page posting 是您可以通过公开包含您的 DataTable 的属性来完成的一件事。另一种选择是在下一页再次填充数据表，如果再次执行它不太昂贵的话。我认为缓存和会话会很昂贵。 Cookie 绝对不是一种选择，因为它会将所有内容都暴露给客户端。
【讨论】：
这取决于你的数据表的内容。
我会排除 Cookie，因为它会强制您将所有数据传输到客户端并返回（猜测如果它是 DataTable，它可以有很多记录）。
会话和缓存都可以工作，但要考虑到只要用户保持会话处于活动状态，它们就可能会存储在内存中。
如果查询不需要很长时间执行，我会考虑再次运行它。
【讨论】：
您可以在 ViewState 中对其进行序列化。
【讨论】：
-
在视图状态下存储的数据越多，页面渲染过程中的页面大小就会增加。
-
ViewState 特定于一页
-
其次，它会向客户端发送大数据和从客户端发送大量数据，这会导致页面响应变慢
-
ViewState 可以通过跨页面发布转移到另一个页面。数据只会和DataTable一样大，需要判断。
会话将是最好的选择。
【讨论】：
-
缓存不是最好的选择，因为你不能保证数据仍然存在。
-
缓存是最糟糕的选择。它是易变的和不可预测的。当服务器检测到内存压力时，可以随时删除项目，这可能发生在页面传输之间。它也不适合支持多个请求，每个请求都需要自己唯一的缓存键。使用 Session、ViewState 或持久化到数据库。
-
@solairaja - 没关系，这非常强调 不是 缓存的用途，因此在某些时候使用 asp.net 缓存可能会产生应用程序负载时出现奇怪的错误。是的，它可能会起作用，但这并不意味着它是正确的或可接受的。
-
@cxfx- 我想说缓存是cookies之后最糟糕的选择。