我有一个问题希望有人能回答,将 Datatable 传输到另一个 .aspx 页面以便它可以收集并绑定到 C# 中的 Gridview 的最佳方法是什么?
- 饼干?
- 会议?
- 缓存?
没有单一的“最佳”——因为它取决于应用程序的结构和您要传输的数据块的大小。它还取决于你在两端用它做什么。
在最基本的层面上,答案是处于会话状态 - cookie 是不合适的,因为(概括)您要移动的数据块太大。缓存是为了避免你不得不重新加载东西,但是(再次概括)你不应该将它用于当你回去查看时你需要在那里的东西,这会让你有会话。
当然,这假设您完全保留了数据表。另一种方法是只维护允许您从存储中检索数据表的键值 - 因此您为第一页加载表一次,做一些事情,保存键值导航到第二页,从存储中重新加载数据表,然后根据需要进行更新。这在概念上是一个更好的模型(它在开销或将表序列化/反序列化到会话与从数据存储中提取数据之间进行权衡,当然数据存储和应用程序之间是缓存数据的合适机会),如果你沿着这条路线走您可以使用会话,或者,如果您愿意,也可以使用 cookie,从而使您摆脱对会话的依赖。
正如我所说,简单、实用的答案在 Session 中——但您需要了解开销以及这对您施加的其他限制。
饼干——绝对不是。会话 - 可能取决于服务器上的用户数/负载。缓存——可能不是一个好主意,除非很多用户查看同一个网格(即数据保证被缓存)。
您不能向其他页面提供一些信息,以允许该页面获取gridview 本身的数据 - 可能像查询字符串参数一样简单,例如productId = 10?
另请阅读ASP.NET 中的跨页发布。
如果您执行重定向到其他页面,这Session
是一个好地方。但如果DataTable
重新创建的成本不太高,我可能会向数据库发送一个新查询。
跨页发布是您可以通过公开包含您的 DataTable 的属性来完成的一件事。另一种选择是在下一页再次填充数据表,如果再次执行它不太昂贵的话。我认为缓存和会话会很昂贵。Cookies 绝对不是一个选项,因为它会将所有内容暴露给客户端。
这取决于数据表的内容。
我会排除 Cookie,因为它会强制您将所有数据传输到客户端并返回(猜测如果它是 DataTable 它可以有很多记录)。
会话和缓存都可以工作,但要考虑到只要用户保持会话处于活动状态,它们就可能会存储在内存中。
如果查询不需要很长时间来执行,我会考虑再次运行它。
您可以在 ViewState 中对其进行序列化。
session 将是最好的选择。