为什么我应该或不应该将数据集,数据表等作为会话变量存储在ASP.N

发布时间：2020-12-16 03:40:51 所属栏目：asp.Net 来源：网络整理

导读：我正在使用Web应用程序,该应用程序正在使用Web服务返回的数据集. 当应用程序运行时,我将该数据集存储为会话变量,以便在用户导航到将编辑数据集中的表的不同页面时反复使用. 想法是用户只需要在应用程序加载时等待一次数据,然后应用程序将使用会话变量,直到用

我正在使用Web应用程序,该应用程序正在使用Web服务返回的数据集.

当应用程序运行时,我将该数据集存储为会话变量,以便在用户导航到将编辑数据集中的表的不同页面时反复使用.

想法是用户只需要在应用程序加载时等待一次数据,然后应用程序将使用会话变量,直到用户保存他们所做的更改,当发生这种情况时,它会将编辑的表传递给服务以更新数据库.

此设计是否存在问题以及将数据集和数据表存储为会话变量？优点与缺点让我知道.

解决方法

唯一的专业是：

>它比重复访问您的数据库更快.也就是说,企业数据库可以提供您不经常需要的足够缓存.

缺点是军团,但主要的三个是：

>如果数据从另一个会话(例如管理员用户)更改,则您的用户的会话不知道
>内存分配很快就会成为一个严重的问题(尽管可以通过使用Cache而不是Session并键入会话ID来缓解这种情况)
>如果您搬到服务器场,您将不得不重新考虑整个设计,很可能使用数据库存储会话数据 – 那么您的效率参数看起来会有点弱

[编辑]正如其他人所指出的那样,在Session或Cache(或者较小程度上的Application)中保存任何内容时也存在问题,而不会将其保留在更永久的地方.如果会话到期,甚至自身重置(我已经看到导致Session开始并以每个请求结束的硬件配置.虽然它保留了Session ID,但是Session对象中存储的任何数据都会丢失.如果应用程序重新启动,无论如何原因是,所有会话,缓存和应用程序对象都被清除.缓存对象可以随时清除这些对象,只是因为环境决定它想要其他内存空间.

总结：这不是要走的路.

如果您需要用户能够进行更改,然后点击“保存”以保留它们,请保留一组单独的状态表,详细说明当用户点击“保存”时应对主表进行的更改.使用密钥在客户端上存储cookie,该密钥将在未来很长的路程中存在;使用该cookie将您的状态数据与用户匹配.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!