在ViewState中存储数据表

Usm*_*lid 5 c# asp.net viewstate datatable memory-management

我正在阅读微软关于州管理的这篇文章.

http://msdn.microsoft.com/en-us/library/75x4ha6s(v=vs.100).aspx

我在这里发现了一件有趣的事.ViewState被归类为Client Side选项(虽然我已经知道了).它让我想起了应用程序中的代码.

DataTable dt = getDatatableFromDB();
ViewState["dataTable"] = dt;
Run Code Online (Sandbox Code Playgroud)

而且这段代码目前工作正常.

我的困惑是:

  1. 客户端对象(ViewState)如何保存服务器端对象(Datatable)?
  2. 使用ViewState存储大型对象(如Datatables)是一种好习惯吗?
  3. 如果我们继续使用这种方法可能会产生副作用(如果有的话)?

JDB*_*JDB 8

视图状态存储在<input />表单上的隐藏标记中.当用户启动回发时(例如,通过单击按钮),数据将作为表单数据的一部分返回到服务器.

如果您在ViewState中存储大量数据,那么当用户尝试下载页面时(因为所有数据都将成为HTML的一部分)以及用户尝试提交表单时,您将受到惩罚(因为所有这些数据必须上传回服务器).

此外,ViewState很容易丢失.只要用户提交表单,它就会被保留.如果用户单击指向另一个页面的超链接,则永远不会提交表单,并且ViewState中包含的所有数据都将丢失.即使锚标记指向用户当前所在的页面也是如此.

我从您之前的问题中看到,您正试图找到一个放置DataTables的好地方.只要数据相对较小,ViewState就不是最糟糕的地方.Base64在内存使用方面优于XML,但距离高效还有很长的路要走.如果数据是相当静态的,您可能需要考虑将其存储在ApplicationState中.如果您使用GridView编辑DataTable,那么GridView实际上已经为您存储了DataTable,您可以通过DataSource属性访问它(只需将其强制转换回DataTable).


值得注意的是,虽然ViewState数据是在base64中编码的(意味着普通用户无法理解它),但可以由确定的用户轻松编辑.看似无害的数据可能会被编辑,对您的网站造成严重危害.这是黑客攻击网站的经典途径,因此您必须非常小心您正在存储的数据.例如,如果您将用户的ID存储在ViewState中,则用户可以编辑该ID并入侵另一个用户的帐户.(注意:如果EnableViewStateMac已设置为,这只是一个问题False.)