Request["key"] vs Request.Params["key"] vs Request.QueryString["key"]答案

【问题标题】：Request["key"] vs Request.Params["key"] vs Request.QueryString["key"]Request["key"] vs Request.Params["key"] vs Request.QueryString["key"]
【发布时间】：2010-02-22 17:45:53
【问题描述】：

Request["key"] vs Request.Params["key"] vs Request.QueryString["key"]

经验丰富的程序员使用哪种方法？为什么？

【问题讨论】：

标签： c# asp.net request.querystring

【解决方案1】：

我推荐Request.QueryString["key"]。对于查询字符串，Request["Key"] 没有太大区别，但如果您尝试从 ServerVariables 获取值，则存在很大差异。 Request["Key"] 在 QueryString 中查找值，如果为 null，则查找 Form，然后是 Cookie，最后是 ServerVariables。

使用Params 是最昂贵的。对 params 的第一个请求会创建一个新的 NameValueCollection 并将每个 QueryString、Form、Cookie 和 ServerVariables 添加到此集合中。对于第二个请求，它比Request["Key"] 性能更高。

话虽如此，几个键的性能差异可以忽略不计。这里的关键是代码应该显示意图，使用Request.QueryString 可以清楚地表明您的意图是什么。

【讨论】：

谢谢，您刚刚回答了我的问题，为什么 cookie 值会从我的 Request.Params[index] 中弹出。
很高兴您注意到在第一次调用时创建了一个新的 NameValueCollection，现在我的错误和堆栈跟踪是有意义的 :)

【解决方案2】：

我更喜欢使用Request.QueryString["key"]，因为它可以帮助代码阅读器准确地了解您从哪里获取数据。我倾向于不使用Request.Params["key"]，因为它可以引用cookie、查询字符串和其他一些东西；所以用户必须考虑一下。人们需要弄清楚你在想什么的时间越少，维护代码就越容易。

【讨论】：

我认为问题出在where 数据来自。使用Request.Params["key"] 很好，只要您实际上不在乎它是来自查询字符串还是来自其他地方。
如果您知道该值包含在哪个集合中，请查看那里。没有用 Request 对象搜索所有集合（出于性能原因，如果没有别的）。
@Will Vousden。好点。当您第一次编写代码并且您的想法很新鲜时，您的观点是非常正确的。快进两年后 - 你有一个讨厌的错误，代码非常多毛/复杂，你只想专注于解决问题！不必寻找填充有“Request.Params[“key”]”（查询字符串、会话变量或其他内容）的变量的含义可以使事情变得更容易一些。它并不大，也不成败，您可以随时查找；但像这样的小事有很长的路要走。

【解决方案3】：

HttpRequest.Params 或 Request.Params 从 httprequest 中获取几乎所有内容（查询字符串、表单、cookie 和会话变量），而 Request.Querystring 只会拉取查询字符串......这一切都取决于你当时在做什么.

【讨论】：

【解决方案4】：

我总是明确指定集合。如果出于某种原因您希望允许覆盖，请为每个“get”编码并编写一些清晰的代码，以显示您的层次结构以选择一个而不是另一个。 IMO，我不喜欢在没有明确商业理由的情况下从多个来源获取价值。

【讨论】：

【解决方案5】：

请注意，如果您在 web.config 下设置 requestValidationMode="4.5"，Request.QueryString[“key”] 和 Request[ “key”] 将使用“延迟加载”行为作为设计。

但是，Request.Params[“key”] 仍然会以某种方式触发验证，就像 4.0 的行为一样。

这种奇怪的行为真的让我困惑了很长时间。

【讨论】：