临时传递值和保存值，...使用会话、隐藏字段、查询字符串或其他？答案

【问题标题】：Passing values and saving values temporarily, ... use session, hidden field, query string or other?临时传递值和保存值，...使用会话、隐藏字段、查询字符串或其他？
【发布时间】：2011-05-12 13:53:55
【问题描述】：

这可能是一个基本问题...但是我只是选择了一个解决方案而没有给予太多考虑...

考虑一个带有表格网格的页面：/FormList.aspx

选择编辑表单会将用户重定向到如下页面：/FormEdit.aspx?Id=2

我通常可以在查询字符串中传递值，因为我在 FormEdit 的代码隐藏中检查了 Id 是否有效。但是，传递值的最佳方式是：会话或查询字符串？还是其他？

当用户编辑表单时...我通常在会话中临时保存 Id（以避免再次从 url 获取它）。在用户的表单编辑过程中，存储值的最佳方式是什么？在会话中还是在隐藏字段中？或其他？（当我想存储一个临时的DataTable时，我相信我只能使用会话，但是当它是一个整数值时......）

提前感谢您的建议:)

【问题讨论】：

看看@在 ViewState 中存储页面特定数据。
我不知道这个选项，我们可以在页面视图状态中存储我们自己的信息（在这种情况下是表单的信息）......我现在将使用查询字符串，但很高兴知道（msdn.microsoft.com/en-us/library/75x4ha6s%28v=VS.90%29.aspx，stackoverflow.com/questions/575568/…）。

标签： c# asp.net session query-string hidden-field

【解决方案1】：

如果要在页面之间传输的数据非常少，通常 QueryString 是一个不错的选择。

2- 当您想要存储用户特定的数据时，Session 将是一个很好的选择。

在您的情况下，最好是查询字符串，因为您将非常小的数据 (ID) 发送到下一页。

【讨论】：

我将使用查询字符串 :) 谢谢！

【解决方案2】：

需要考虑的几点：

如果对值的操作存在安全风险，则需要将其保存在服务器端，或者保护值客户端（这不容易纠正）。甚至更好：重新计算它们。
如果用户同时在多个选项卡中打开网站，则在会话中保存很容易产生问题。它还可以破坏返回按钮。
例如，如果您保护了用户当前在会话中编辑的项目的 ID，并且用户同时编辑了两个条目，则他首先开始编辑的条目的内容可能会写入他稍后开始编辑的条目中。

【讨论】：

没想到用户编辑同一类型的多个页面......所以会话应该是针对用户特定的信息，而不是特定于表单的。谢谢！也感谢您提出安全问题，我正在处理的表单不是敏感信息，所以我将只使用查询字符串（可能还有隐藏字段）但是，我会记住这一点。

【解决方案3】：

我建议不要将Session 用于可以在查询字符串或隐藏表单字段中轻松快速地存储和检查的内容；您似乎在这里谈论的信息非常适合查询字符串。

请注意，Session 可能会在有人尝试在不同选项卡中同时编辑多个表单时引入错误。当他们保存一个时，所取的Session 值将来自他们加载的最后一个保存...可能不是您想要的，而且可能很难弄清楚这一点。

您应该做的是在查询字符串/表单字段中保留 formID，并在提交保存时仔细检查它的完整性；例如，确保它是一个存在的 ID，并且允许他们进行编辑。

【讨论】：

其实我没有想过用户同时编辑多个表单……那么使用会话存储表单信息不是一个好的选择。我将使用查询字符串来传递值，并保存表单，我将从查询字符串或隐藏字段中获取 id（是的，检查 id 是否有效并且用户可以编辑它） .谢谢！

【解决方案4】：

我的建议是将值保存在会话变量中，但是当您第一次运行 FormEdit.aspx 的 page_load 时，将值保存在页面的 ViewState 中，并清除会话变量。

类似的东西（在 FormEdit.aspx 的 page_load 中）：

if (!IsPostBack)
{
    ViewState["MyVar"] = Session["MyVar"];
    Session.Remove("MyVar");
}

【讨论】：

【解决方案5】：

ASP.NET 和查询字符串的问题在于它们在回发时仍然存在。也就是说，任何页面的表单操作默认为 url包括用于加载它的查询字符串。

如果所讨论的 ID 仅用于选择特定表单（并且与用户数据无关），这没什么大不了的，实际上它可能正是您想要的。

另一方面，如果它标识了一条记录，您可能不希望这样做。假设您正确编码，这不应该带来安全风险，但它可以通过在查询字符串中公开记录的内部 ID 给用户一种印象，即存在安全风险。它看起来也很不幸。

有一些方法可以解决这个问题，我认为在 3.5 中您可以通过编程方式更改表单操作。（以前您必须使用 javascript 来执行此操作 - 即使表单操作已公开，也无法更改）。

处理此问题的最佳方法是避免使用任何数据记录标识符的查询字符串。改为使用 POST 加载数据记录，例如不要使用 asp:HyperLink 控件，而是使用 asp:LinkButton 控件。

当然，由于 POSTS 加载它们的来源相同的页面，这要求您的表单与列表位于同一页面上。因此，不要有两个单独的页面，FormList.aspx 和 FormEdit.aspx，只需将代码放在同一页面上，这样您就可以直接回帖。大概您的每个表单都在 UserControl 中。因此，您的主页只需要选择要显示的用户控件，其他所有内容都委托给用户控件，并且所有参数传递都可以通过主页内的帖子完成。这是一个更好的架构，可以让一切保持整洁。

【讨论】：