据我所知，在asp.net的会话变量中存储DataTable很糟糕，因为它会占用很多服务器的内存。我不明白的是那时你做什么：
感谢您的帮助。
答案 0 :(得分：7)
DataTable是非常重的对象，不建议将其存储在ViewState或Session中。您描述的方案是关于缓存数据。那么，为什么不使用ASP.NET的缓存呢？
ViewState ，虽然它不会像服务器或缓存那样在服务器上使用尽可能多的内存，但仍需要服务器上的序列化/反序列化，除了为用户提供一些临时内存使用外每个请求进出服务器的大量数据（只需在任何浏览器中查看View Source，你就会看到一个带有base-64编码数据的非常大的隐藏输入）。如果您不使用加密，任何人都可以解码每个请求中传递的数据，如果任何数据敏感，则会导致潜在的安全问题。 ViewState也适用于少量数据，通常最好坚持主要数据类型，如整数和字符串。
会话通常也不是一个好主意，因为它还需要序列化/反序列化，除了每个用户的内存压力之外，还会增加额外的开销。会话具有memory limits，当您增加并发用户时，每个用户会减少。会话数据在每个用户的实际会话到期之前不会“过期”，默认情况下为30分钟。 Session非常适合用户特定的数据，但建议保持非常小，并再次坚持主要数据类型，如整数和字符串。
缓存不会序列化任何数据，仅由于操作系统的位数而导致limited in size。在Windows 2003 32位上，您可以使用800 MB的总应用程序池大小（如果使用/ 3GB开关，则为1.2或1.3 GB）。在64位下，有更多的自由和限制，实际上只是你配置的可用系统内存量。缓存的好处是，随着内存压力的增加，缓存可以过期以释放内存以用于更重要的事情。当内存压力不是一个因素（无法保证到期时）时，您还可以控制项目何时到期。如果使用SQL Server，则可以对数据库中的数据设置缓存依赖性，允许数据本身决定何时使缓存过期，从而确保新数据。
最后，可以使用经常被遗忘的应用程序对象，但仅适用于您知道可以跨用户共享的数据，并且不需要经常更改（希望在应用程序重新启动之前）
使用Microsoft针对ViewState，Session，Cache和Application个对象的文档，确定每个对象的最明智用途。除了使用AJAX（以避免整页回发）和HTTP压缩以减少传送到客户端的有效负载之外，正确使用这些的组合可以构成响应非常快的站点。
在Web场和负载平衡等更复杂的场景中，还有其他问题需要考虑。您需要问自己的问题是：如果用户遇到的服务器与最初请求的服务器不同，是否应该创建新会话？无论用户点击什么服务器，都应该缓存工作吗？这些问题将为您带来可能会改变存储数据的解决方案。 InProc Session比使用SQL Server作为会话服务器更宽容，因为还有其他序列化限制。
答案 1 :(得分：1)
另一种存储DataTable的方法是ViewState，如果您只想在页面级别使用它。 ViewState["dtbl"] = DataTable;
您可以从ViewState简单DataTable dtbl = (DataTable)ViewState["dtbl"];