传递值并临时保存值，...使用会话、隐藏字段、查询字符串或其他？
这可能是一个基本问题...但是我只是选择了一个解决方案，而没有考虑太多...
考虑一个带有表单网格的页面：/FormList.aspx
，其中选择编辑表单将用户重定向到如下页面： /FormEdit.aspx?Id=2
我通常可以在查询字符串中传递值，因为我检查 FormEdit 的代码隐藏该 ID 有效。不过，传递值的最佳方式是：会话还是查询字符串？还是其他？
当用户编辑表单时...我通常将 ID 临时保存在会话中（以避免再次从 url 获取它）。在用户表单编辑期间，存储值的最佳方式是什么？在会话中还是在隐藏字段中？还是其他？ （当我想存储临时数据表时，我相信我只能使用会话，但是当它是整数值时......）
预先感谢您的建议:)
This may be a basic question... However I've just been picking a solution without giving much though to it...
Consider a page with a grid of forms: /FormList.aspx
where choosing to edit a form redirects the user to a page like: /FormEdit.aspx?Id=2
I usually am okay with passing the values in the query string, because I check in the code-behind of FormEdit that the Id is valid. Which is the best way to pass the value, though: session or query string? Or other?
While the user is editing the form... I usually save the Id temporarily in session (to avoid getting it from the url again). During the user's form edition, what is the best way to store the value? In the session or in a hidden field ? Or other? (When I want to store a temporary DataTable, I believe I can only use the session, but when it's an integer value...)
Thanks in advance for your suggestions :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我建议不要将
Session用于可以轻松快速地在查询字符串或隐藏表单字段中存储和检查的内容；您似乎在这里谈论的信息非常适合查询字符串。请注意，当有人尝试在不同的选项卡中同时编辑多个表单时，
Session可能会引入错误。当他们保存一个时，所获取的Session值将来自他们加载保存的最后一个值......可能不是您想要的，并且可能很难弄清楚这一点。您应该做的是将 formID 保留在查询字符串/表单字段中，并在提交保存时仔细检查其完整性；例如，确保该 ID 存在并且允许他们进行编辑。
I would suggest not to use
Sessionfor something that can easily and quickly be stored and checked in a query string or hidden form field; the information you seem to be talking about here is perfect for the query string.Note that
Sessioncould introduce bugs when someone attempts to edit multiple forms at once in different tabs. When they save one, theSessionvalue taken would be from the last one they loaded up to save... likely not what you will want, and it would likely be difficult to figure this out.What you should do is persist the formID in the query string/form fields, and just double-check it for sanity when they submit the save; Make sure it's an ID that exists and that they are allowed to edit, for example.
通常，如果要在页面之间传输的数据非常小，则 QueryString 是一个不错的选择。
2-当您想要存储用户特定数据时，会话会是一个很好的选择。
在您的情况下，最好是查询字符串，因为您要向下一页发送非常小的数据（ID）。
Normally QueryString is a good choice if you are having very small data to trasfer between your pages.
2- Session would be a great when you want to store user specific data.
in you case , best would be the querystring as you are sending very small data (ID ) to the next page.
需要考虑的一些事情：
例如，如果您保护用户当前在会话中编辑的项目的 ID，并且用户同时编辑两个条目，则他首先开始编辑的条目的内容可能会写入他稍后开始编辑的条目中。
A few things to consider:
For example if you safe the ID of the item the user is currently editing in the session, and the user edits two entries at the same time the content of the one he started editing first might be written into the entry he started editing later.
我的建议是将值保留在会话变量中，但是当您第一次运行FormEdit.aspx的page_load时，将该值保存在页面的ViewState中，并清除会话变量。
类似的东西（在 FormEdit.aspx 的 page_load 中）：
My suggestion is to keep the value in a session variable, but when you run the page_load of FormEdit.aspx for first time, save the value in the ViewState of the page, and clear the session var.
Something like that (in page_load of FormEdit.aspx):
ASP.NET 和查询字符串的问题在于它们在回发时仍然存在。也就是说，任何页面的表单操作默认为 URL ，包括用于加载它的查询字符串。
如果有问题的 ID 只是用于选择特定的表单（与用户数据无关），这没什么大不了的，事实上这可能就是您想要的。
另一方面，如果它标识一条记录，您可能不希望这样。假设您正确编码，这应该不会带来安全风险，但它可能会通过暴露查询字符串中记录的内部 ID 给用户留下存在安全风险的印象。它看起来也很不幸。
有多种方法可以解决这个问题，我认为在 3.5 中您可以通过编程方式更改表单操作。 （过去您必须使用 javascript 来执行此操作 - 即使表单操作已公开，但也无法更改）。
处理此问题的最佳方法是避免使用任何数据记录标识符的查询字符串。使用 POST 加载数据记录，例如，不使用 asp:HyperLink 控件，而使用 asp:LinkButton 控件。
当然，由于帖子加载它们来源的同一页面，这要求您的表单与列表位于同一页面上。因此，无需将
FormList.aspx和FormEdit.aspx这两个单独的页面放在一起，只需将代码放在同一页面上即可直接回发。想必您的每个表单都位于 UserControl 中。因此，您的主页只需选择要显示的用户控件，其他所有内容都委托给用户控件，并且所有参数传递都可以通过主页内的帖子完成。这是一个更好的架构，让一切都变得漂亮和干净。The problem with ASP.NET and query strings is that they persist on postbacks. That is, the form action for any page defaults to the url including the query string that was used to load it.
If the ID in question is just used to choose a particular form (and is not related to user data) this is not a big deal, in fact it's probably what you want.
On the other hand, if it identifies a record, you may not want this. Assuming you code things properly, this should not present a security risk, but it can give the user the impression that there is one by exposing the internal ID of a record in the query string. It also just looks unfortunate.
There are ways to work around this, and I think in 3.5 you can programatically change the form action. (It used to be you had to use javascript to do that - even though the form action was exposed it could not be changed).
The best way to deal with this is avoid query strings for any data record identifiers. Use POSTs to load data records instead, e.g. instead of using an asp:HyperLink control, use an asp:LinkButton control.
Of course, since POSTS load the same page they are sourced from, this requires that your forms be on the same page as your list. So, instead of having two separate pages,
FormList.aspxandFormEdit.aspx, just put the code on the same page so you can post back directly. Presumably each of your forms is in a UserControl anyway. So your main page just has the job of choosing which usercontrol to show, everything else is delegated to the user controls, and all the parameter-passing can be done through posts inside your main page. This is a better architecture and keeps everything nice and clean.