在asp.net会话中存储DataTable对象的坏主意

ton*_*ony 5 .net c# asp.net datatable session

我知道在asp.net中的会话变量中存储DataTable是不好的,因为它将使用大量服务器的内存.我不明白的是那时你做什么:

  1. 用户进入需要加载DataTable对象的页面(来自SQL Server).
  2. 用户单击单选按钮以执行简单事件(例如,某些控件被禁用).
  3. 如果不在会话中保存DataTable对象,则必须在同一页面上回发时再从SQL Server加载它而不是仅从会话中获取它?

感谢帮助.

Sum*_*umo 7

DataTable是非常重的对象,不建议将其存储在ViewState或Session中.您描述的方案是关于缓存数据.那么,为什么不使用ASP.NET的缓存呢?

ViewState虽然不会像服务器或缓存一样在服务器上使用尽可能多的内存,但仍需要在服务器上进行序列化/反序列化,需要一些临时内存使用,此外还要为每个请求的用户提供大量的数据有效负载.服务器(只需在任何浏览器中查看View Source,您将看到一个包含base-64编码数据的非常大的隐藏输入).如果您不使用加密,任何人都可以解码每个请求中传递的数据,如果任何数据敏感,则会导致潜在的安全问题.ViewState也适用于少量数据,通常最好坚持使用int和字符串等主要数据类型.

会话通常不是一个好主意,因为它还需要序列化/反序列化,除了每个用户的内存压力之外,这还增加了额外的开销.会话具有内存限制,当您增加并发用户时,每个用户会减少.会话数据在每个用户的实际会话到期之前不会"过期",默认情况下为30分钟.Session非常适合用户特定的数据,但建议保持非常小并再次坚持主要数据类型,如整数和字符串.

高速缓存不会序列化任何数据,并且仅由于操作系统的位数而限制大小.在Windows 2003 32位上,您可以使用800 MB的总应用程序池大小(如果使用/ 3GB开关,则为1.2或1.3 GB).在64位下,有更多的自由和限制,实际上只是你配置的可用系统内存量.缓存的好处是,随着内存压力的增加,缓存可以过期以释放内存以用于更重要的事情.当内存压力不是一个因素(无法保证到期时)时,您还可以控制项目何时到期.如果使用SQL Server,则可以采取额外的步骤,并且可以对数据库中的数据设置缓存依赖性,允许数据本身决定何时使缓存过期,从而确保新数据.

最后,可以使用经常被遗忘的Application对象,但仅限于您知道可以跨用户共享的数据,并且不需要经常更改(希望在应用程序重新启动之前).

使用Microsoft的ViewState,Session,CacheApplication对象文档,确定每种方法最适合您的特定方案.除了使用AJAX(以避免整页回发)和HTTP压缩以减少传送到客户端的有效负载之外,正确使用这些的组合可以构成响应非常快的站点.

在Web场和负载平衡等更复杂的场景中,还有其他需要考虑的问题.您需要问自己的问题是:如果用户遇到的服务器与最初请求的服务器不同,是否应该创建新会话?无论用户点击什么服务器,都应该缓存工作吗?这些问题将为您带来可能会改变存储数据的解决方案.InProc Session比使用SQL Server作为会话服务器更宽容,因为还有其他序列化限制.


Muh*_*tar 1

如果您只想在页面级别使用 DataTable,则另一种存储 DataTable 的方法是在ViewState.ViewState["dtbl"] = DataTable;

您可以从ViewStateSimply访问它DataTable dtbl = (DataTable)ViewState["dtbl"];

  • 通常(在内网环境中)将空洞 DataTable 存储在 ViewState 中会比存储在 Session 中导致更多的性能问题。 (7认同)
  • 我工作中的某人认为在 ViewState 中存储 DataTable 是个好主意...然后我指出 aspx 页面的大小是 17MB... (4认同)