在ASP.NET中可以接受使用Session变量而苦苦挣扎

Question

我试图让自己在ASP.NET中的一个Session变量中删除所有内容（我来自Windows编程背景），我通常完全停止在Session变量中显式存储任何内容。任何人都可以给出一些关于你认为对会话变量的可接受使用的指导吗？

这是一个具体的例子......我从数据库加载一个业务对象并填充和编辑屏幕。用户可以编辑值并保存。旧方法我将加载业务对象，加载我的表单，并将业务对象保存到会话变量。如果用户单击了save，我将从会话变量中检索业务对象，替换已编辑的值，然后保存它。我从数据库加载业务对象并加载我的表单的新方法。用户将编辑值并单击“保存”。我将从数据库重新加载我的业务对象，替换编辑的值，然后保存它。我不是网络编程专家，但我觉得第一种方法是错误的，因为使用会话变量的不好的耻辱，我觉得第二种方式是错误的，因为它只是感觉像一个糟糕的方式（加载业务对象两次） ）。我们不要在这里考虑任何形式的缓存。我该如何处理？

Answer 1

通过在帖子上重新加载数据库中的业务对象来保存用户更改，我并不感到冒犯。

该对象必须来自该回发的某个地方，并且与快速数据库调用相关的有限开销（如抓取特定对象）可能是您最好的选择。

您可以选择在回发后将该业务对象恢复到内存中：

• 再次从数据库中获取它。缺点：一些（小）额外的数据库开销
• 将其保存在用户的会话中。缺点：可能仍然访问数据库（如果会话状态存储在那里）或使用大量内存（如果存储会话状态），并且如果多个用户可能正在访问此对象，则可能正在存储多个副本，最糟糕的是，该会话如果ASP.NET因任何原因清除它，那么对象可能会随着用户点击提交而消失。
• 来自缓存。缺点：使用一些额外的内存，如果缓存不存在，你仍然需要转到数据库，但我会花大钱，任何应用程序都有很多更大的瓶颈来使用缓存。
• 视图状态。您可以将对象存储在Viewstate中（将其发送到客户端，然后客户端将其发回）。缺点：在我看来，最糟糕的解决方案。将它添加到Viewstate意味着它会越过下游和上游的线路，导致页面大小变大。会话不是最好的，但Viewstate是魔鬼。

Answer 2

你有很多用户吗？

如果您的网站数量较少，则将您的业务对象存储在会话中可能没问题。

如果您使用SQL Server来存储会话，那么无论如何您都会从每个帖子中有效地从数据库加载业务对象。

根据经验，我倾向于使用Session来存储适用于用户会话生命周期的信息。特定于单个Web表单的业务对象并不真正适合此类别。对于大批量网站，此策略可能会帮助您更好地扩展。这取决于所有相关因素。

：）

Answer 3

在更新之前从数据库重新加载对象可能非常危险。您最终可能会遗漏任何可能的并发冲突。

例如，如果发生此流程：

1. 在计算机1上显示客户1的编辑屏幕
2. 在计算机2上显示客户1的编辑屏幕
3. 从计算机1处理客户1的更新
4. 从计算机2处理对客户1的更新

由于并发冲突，（4）可能会失败，即更新会覆盖计算机2不知道的更改。但是通过从数据库重新加载，您忽略了这些问题并实现了最后的更新获胜。

因此，对于这种情况，我觉得如果你关心并发性，那么将原始实体放在会话中（或者在表单上的隐藏字段中）是绝对正确的。

更不用说很多人不喜欢再次点击数据库进行额外的阅读......