Request [“ key”] vs Request. Params [“ key”] vs Request.QueryString [“ key”]

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

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

HttpRequest.Params或者 Request.Params从 httprerequest 中获取几乎所有的东西(查询字符串、表单、 cookie 和会话变量) ，而 Request.Querystring只获取查询字符串... ... 所有这些都取决于你当时在做什么。

我推荐 Request.QueryString["key"]。对于查询字符串来说，与 Request["Key"]没有太大的区别，但是如果您试图从 ServerVariables获取值，则会有很大的区别。如果为空，Request["Key"]在 QueryString中查找一个值，它查找 Form，然后是 Cookie，最后是 ServerVariables。

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

已经说过，两个键的性能差异是可以忽略不计的。这里的关键是代码应该显示意图，使用 Request.QueryString可以清楚地表明你的意图是什么。

友情提示，如果在 web.config 下设置 RequestValidationMode = “4.5”，则 Request.QueryString [“ key”]和 要求[“钥匙”]都将使用“延迟加载”行为作为设计。

但是，请求仍然会以4.0的行为触发验证。

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

总是发现使用 request.querystring 定位 url 参数更有用，这样就省去了试图跟踪可以从其他不同位置获取的其他值的麻烦。