随笔 - 58  文章 - 0  评论 - 6027  0

今天我来谈一谈容易被人混淆的二个集合:Request[]与Request.Params[]

这二个集合我在博客【我心目中的Asp.net核心对象】中就提到过它们, 而且还给出了一个示例,并以截图的形式揭示过它们的差别。但由于那篇博客中有更多有价值的对象要介绍, 因此也就没有花太多的篇幅着重介绍这二个集合。但我发现,不知道这二个集合差别的人确实太多,以至于我认为很有必要为它们写个专题来细说它们的差别了。

在ASP.NET编程中,有三个比较常见的来自于客户端的数据来源:QueryString, Form, Cookie 。 我们可以在HttpRequest中访问这三大对象, 比如,可以从QueryString中获取包含在URL中的一些参数, 可以从Form中获取用户输入的表单数据, 可以从Cookie中获取一些会话状态以及其它的用户个性化参数信息。 除了这三大对象,HttpRequest还提供ServerVariables来让我们获取一些来自于Web服务器变量。 通常,这4个数据来源都很明确,我想没人会混淆它们。

一般情况下,如果我们在事先就能明确知道某个参数是来源于哪个集合,那么直接访问那个集合,问题也就简单了。 然而,更常见的数据来源通常只会是QueryString, Form ,而且尤其是当在客户端使用Jquery的$.ajax()这类技术时, 可以很随意地将参数放到QueryString或者是Form中,那么,服务端通常为了也能灵活地应对这一现况, 可以使用Request[]与Request.Params[] 这二种方式来访问这些来自于用户提交的数据。 本文的故事也因此而产生了:Request[]与Request.Params[] 有什么差别??

回顾博客原文

由于【我心目中的Asp.net核心对象】有对它们的一些介绍以及示例截图, 无奈,有些人可能由于各种原因,没看到那段文字,这里我也只好再贴一次了:


这二个属性都可以让我们方便地根据一个KEY去【同时搜索】QueryString、Form、Cookies 或 ServerVariables这4个集合。 通常如果请求是用GET方法发出的,那我们一般是访问QueryString去获取用户的数据,如果请求是用POST方法提交的, 我们一般使用Form去访问用户提交的表单数据。而使用Params,Item可以让我们在写代码时不必区分是GET还是POST。 这二个属性唯一不同的是:Item是依次访问这4个集合,找到就返回结果,而Params是在访问时,先将4个集合的数据合并到一个新集合(集合不存在时创建), 然后再查找指定的结果。
为了更清楚地演示这们的差别,请看以下示例代码:

<body>    
    <p>Item结果:<%= this.ItemValue %></p>
    <p>Params结果:<%= this.ParamsValue %></p>
    
    <hr />
    
    <form action="<%= Request.RawUrl %>" method="post">
        <input type="text" name="name" value="123" />
        <input type="submit" value="提交" />
    </form>
</body>

public partial class ShowItem : System.Web.UI.Page
{
    protected string ItemValue;
    protected string ParamsValue;

    protected void Page_Load(object sender, EventArgs e)
    {
        string[] allkeys = Request.QueryString.AllKeys;
        if( allkeys.Length == 0 )
            Response.Redirect("ShowItem.aspx?name=abc", true);


        ItemValue = Request["name"];
        ParamsValue = Request.Params["name"];        
    }
}

页面在未提交前浏览器的显示:

点击提交按钮后,浏览器的显示:

差别很明显,我也不多说了。说下我的建议吧:尽量不要使用Params,不光是上面的结果导致的判断问题, 没必要多创建一个集合出来吧,而且更糟糕的是写Cookie后,也会更新集合。


正如我前面所说的客观原因:由于那篇博客中有更多有价值的对象要介绍,因此也就没有花太多的篇幅着重介绍这二个集合。 下面,我来仔细地说说它们的差别。

实现方式分析

前面的示例中,我演示了在访问Request[]与Request.Params[] 时得到了不同的结果。为什么会有不同的结果呢,我想我们还是先去看一下微软在.net framework中的实现吧。

首先,我们来看一下Request[]的实现,它是一个默认的索引器,实现代码如下:

public string this[string key]
{
    get
    {
        string str = this.QueryString[key];
        if( str != null ) {
            return str;
        }
        str = this.Form[key];
        if( str != null ) {
            return str;
        }
        HttpCookie cookie = this.Cookies[key];
        if( cookie != null ) {
            return cookie.Value;
        }
        str = this.ServerVariables[key];
        if( str != null ) {
            return str;
        }
        return null;
    }
}

这段代码的意思是:根据指定的key,依次访问QueryString,Form,Cookies,ServerVariables这4个集合,如果在任意一个集合中找到了,就立即返回。

Request.Params[]的实现如下:

public NameValueCollection Params
{
    get
    {
        //if (HttpRuntime.HasAspNetHostingPermission(AspNetHostingPermissionLevel.Low))
        //{
        //    return this.GetParams();
        //}
        //return this.GetParamsWithDemand();

        // 为了便于理解,我注释了上面的代码,其实关键还是下面的调用。
        return this.GetParams();
    }
}
private NameValueCollection GetParams()
{
    if( this._params == null ) {
        this._params = new HttpValueCollection(0x40);
        this.FillInParamsCollection();
        this._params.MakeReadOnly();
    }
    return this._params;
}
private void FillInParamsCollection()
{
    this._params.Add(this.QueryString);
    this._params.Add(this.Form);
    this._params.Add(this.Cookies);
    this._params.Add(this.ServerVariables);
}

它的实现方式是:先判断_params这个Field成员是否为null,如果是,则创建一个集合,并把QueryString,Form,Cookies,ServerVariables这4个集合的数据全部填充进来, 以后的查询都直接在这个集合中进行。

我们可以看到,这是二个截然不同的实现方式。也就是因为这个原因,在某些特殊情况下访问它们得到的结果将会不一样。
不一样的原因是:Request.Params[]创建了一个新集合,并合并了这4个数据源,遇到同名的key,自然结果就会不同了。

再谈Cookie

在博客【我心目中的Asp.net核心对象】中, 说到Request.Params[]时,我简单地说了一句:而且更糟糕的是写Cookie后,也会更新集合。 如何理解这句话呢?

我想我们还是来看一下我们是如何写一个Cookie,并发送到客户端的吧。下面我就COPY一段 【细说Coookie】中的一段原文吧:


Cookie写入浏览器的过程:我们可以使用如下代码在Asp.net项目中写一个Cookie 并发送到客户端的浏览器(为了简单我没有设置其它属性)。

HttpCookie cookie = new HttpCookie("MyCookieName", "string value");
Response.Cookies.Add(cookie);

代码的关键点在于调用了Response.Cookies.Add(),我们来看看它们是如何实现的。首先来看Response.Cookies

public HttpCookieCollection Cookies
{
    get
    {
        if (this._cookies == null)
        {
            this._cookies = new HttpCookieCollection(this, false);
        }
        return this._cookies;
    }
}

再来看HttpCookieCollection这个集合的实现:

public sealed class HttpCookieCollection : NameObjectCollectionBase
{
    public HttpCookieCollection() : base(StringComparer.OrdinalIgnoreCase)
    {
    }

    internal HttpCookieCollection(HttpResponse response, bool readOnly) 
        : base(StringComparer.OrdinalIgnoreCase)
    {
        this._response = response;
        base.IsReadOnly = readOnly;
    }

    public void Add(HttpCookie cookie)
    {
        if (this._response != null)
        {
            this._response.BeforeCookieCollectionChange();
        }
        this.AddCookie(cookie, true);
        if (this._response != null)
        {
            this._response.OnCookieAdd(cookie);
        }
    }

注意:由于在HttpResponse中创建HttpCookieCollection时,把HttpResponse对象传入了,因此,在调用HttpCookieCollection.Add()方法时, 会调用HttpResponse的OnCookieAdd(cookie); 我们接着看:

internal void OnCookieAdd(HttpCookie cookie)
{
    this.Request.AddResponseCookie(cookie);
}

又转到Request对象的调用了,接着看:

internal void AddResponseCookie(HttpCookie cookie)
{
    if (this._cookies != null)
    {
        this._cookies.AddCookie(cookie, true);
    }
    if (this._params != null)
    {
        this._params.MakeReadWrite();
        this._params.Add(cookie.Name, cookie.Value);
        this._params.MakeReadOnly();
    }
}

从以上的代码分析中,我们可以看到,我们调用Response.Cookies.Add()时,Cookie也会加到HttpRequest.Cookies中。
而且,如果我们访问过程Request.Params[],也会加到那个集合中。

再谈NameValueCollection

本文一开始的示例中,为什么代码 ParamsValue = Request.Params["name"]; 得到的结果是:【abc,123】?

根据前面示例代码我们可以得知:abc这个值是由QueryString提供的,123这值是由Form提供的,最后由Request.Params[]合并在一起了就变成这个样子了。 有没有人想过:为什么合起来就变成了这个样子了呢?

要回答这个问题,我们需要回顾一下Params的定义:


public NameValueCollection Params

注意:它的类型是NameValueCollection 。MSDN对这个集合有个简单的说明:

此集合基于 NameObjectCollectionBase 类。但与 NameObjectCollectionBase 不同,该类在一个键下存储多个字符串值。

为了便于大家更容易理解这个类的工作方式,我画了一张草图:

【name】这个key对应差一个ArrayList,而那个ArrayList中,包含了二个字符串:abc 和 123 ,这就是它的工作方式。

既然它能在一个键值下存储多个字符串,那我们就来看一下它到底是如何实现的,直接转到Add()方法:(注意我在代码中添加的注释)

public virtual void Add(string name, string value)
{
    if( base.IsReadOnly ) {
        throw new NotSupportedException(SR.GetString("CollectionReadOnly"));
    }
    this.InvalidateCachedArrays();

    // 这是一个关键的调用,它调用基类,得到每个name对应的元素,
    // 而每个name对应的元素是一个ArrayList
    ArrayList list = (ArrayList)base.BaseGet(name);

    if( list == null ) {
        // 如果不存在name对应的元素,则创建ArrayList
        list = new ArrayList(1);
        if( value != null ) {
            // 添加value到ArrayList,它将是第一个值
            list.Add(value);
        }
        base.BaseAdd(name, list);
    }
    else if( value != null ) {
        // 在原有的ArrayList中继续添加新的值
        list.Add(value);
    }
}

我们再来看一下当我们访问Params[]这个索引器时,.net framework又是如何实现的:

public string this[string name]
{
    get { return this.Get(name); }
    set { this.Set(name, value); }
}
public virtual string Get(string name)
{
    // 根据name得到ArrayList
    ArrayList list = (ArrayList) base.BaseGet(name);
    // 将ArrayList变成一个字符串行
    return GetAsOneString(list);
}

private static string GetAsOneString(ArrayList list)
{
    int num = (list != null) ? list.Count : 0;
    if( num == 1 ) {
        return (string)list[0];
    }
    if( num <= 1 ) {
        return null;
    }
    StringBuilder builder = new StringBuilder((string)list[0]);
    for( int i = 1; i < num; i++ ) {
        builder.Append(',');    // 逗号就来源于此。
        builder.Append((string)list[i]);
    }
    return builder.ToString();
}

现在,您该明白了为什么当一个key有多个值时,为什么会用逗号分开来了吧。

或许,看到这里,您又有了一个新的想法:对于有多值的情况,还要我来按逗号拆分它们,太麻烦了,有没有不要拆分的方法呢?

答案是:有的,您可以访问NameValueCollection的GetValues方法,这个方法的实现如下:

public virtual string[] GetValues(string name)
{
    ArrayList list = (ArrayList)base.BaseGet(name);
    return GetAsStringArray(list);
}
private static string[] GetAsStringArray(ArrayList list)
{
    int count = (list != null) ? list.Count : 0;
    if( count == 0 ) {
        return null;
    }
    string[] array = new string[count];
    list.CopyTo(0, array, 0, count);
    return array;
}

我想结果一定是您所期待的,它是一个string[] ,我们可以方便的遍历它:


string[] array = Request.Params.GetValues("name");
if( array != null )
    foreach(string val in array)
    

再谈QueryString, Form

前面我解释了NameValueCollection的工作原理,并揭示了Request.Params["name"]; 得到【abc,123】这个结果的原因。
事实上,这个怪异的结果有时并不只是Params会有,同样的故事还可能由QueryString, Form这二个对象上演(最终会在Request[]那里也有体现)。

我还是拿【我心目中的Asp.net核心对象】的示例来说明吧:

protected void Page_Load(object sender, EventArgs e)
{
    string[] allkeys = Request.QueryString.AllKeys;
    if( allkeys.Length == 0 )
        Response.Redirect(
            Request.RawUrl + "?aa=1&bb=2&cc=3&aa=" + HttpUtility.UrlEncode("5,6,7"), true);

    StringBuilder sb = new StringBuilder();
    foreach( string key in allkeys )
        sb.AppendFormat("{0} = {1}<br />", 
            HttpUtility.HtmlEncode(key), HttpUtility.HtmlEncode(Request.QueryString[key]));

    this.labResult.Text = sb.ToString();
}

页面最终显示结果如下(注意键值为aa的结果):


示例代码中,开始部分用于检查URL是否包含参数,如果没有,则加入一些参数。写成这样的原因是: 第一次访问这个页面时,URL中肯定是不包含参数的,为了能演示,所以我就加了一些固定的参数,这样便于后面的讲解。

这个示例也演示了:遇到同名的多个值,用逗号分开的做法,并不是Params才会有的,QueryString也可能会有, 当然,Form也逃不掉这个特性的缠绕,不过,我现在倒想举个有使用价值的示例。

我有这样一个录入界面(左边),并希望最终的录入结果以右图的方式显示:

我想这个功能的实现并不难,但如何做才是最简单呢?

下面我贴出我的实现方法,大家看看算不算比较容易:


    <tr><td style="vertical-align: top">项目类型</td><td>
    <% foreach( string pt in AppHelper.ProjectTypes ) { %>
        <label><input type="checkbox" name="ProjectType" value="<%= pt %>" /><%= pt%></label><br />
    <% } %>
        </td></tr>

注意:所有的checkbox的name都是一样的。

服务端嘛,我认为没有必要再贴代码了,我想您懂的。

在这个示例中,我正好利用了NameValueCollection的这个特点,让它帮我实现了这个逗号分隔的效果,要不然,我还得自己去做!

如何处理冲突

通过前面的一些示例,我们可以看到并非只有Params[]会有冲突,只要类型是NameValueCollection的数据源,都有这个问题。
我要再重申一次:QueryString, Form,Param都有这样的冲突问题,只是Param需要合并4种数据源,它将冲突的机率变大了。

那么,我们如何正确的处理这类冲突呢? 还记得我前面提到的NameValueCollection的GetValues方法吧,也只好用它了。(除非你愿意自己手工拆分字符串) 然后再用一个循环就可以访问所有冲突值了,就像下面这样:


string[] array = Request.Params.GetValues("name");
if( array != null )
    foreach(string val in array)
    

注意:Request[]的返回结果是一个字符串,就不能使用这种方法。但是,它的冲突机率要少很多。

现在,还有个现实的问题:QueryString, Form是最常用的数据源,我们要不要这样处理它呢?
这的确是个很现实的问题,我认为在回答这个问题前,我们需要分析一下这二个集合出现KEY冲突时是个什么样子的。

1. "abc.aspx?id=1 &id=2" 在这URL中,我想问问各位:看到这个URL,您会怎么想?我认为它是错的,错在拼接URL的操作中。 其次,我认为URL的修改或者拼接通常由一个工具类来控制,我们有理由保证它不会出现冲突,毕竟范围相应较小,我们容易给出这个保证。 因此,我认为,直接访问QueryString可以忽略这种冲突的可能。

2. 表单数据中name重复的情况。我认为这个集合倒是有可能出现冲突,但也极有可能是我们故意安排的,就像前面的示例一样。 其次,表单的内容在开发阶段相对固定,各个输入控件的name也是比较清楚的,不存在动态变换的可能,因此, 我认为,直接访问Form也可以忽略这种冲突的可能。

另一方面,我们平时写QueryString[], Form[]都太习惯了,这样的代码太多了,也不可能改成循环的判断, 因此,我们只能尽量保证在一个数据源的范围内,它们是不重复的。 事实上,前二个集合通常仅仅与某一个页面相关,范围也相对较小,更容易保证。 因此,如果有了这个保证,在访问这二类集合时,忽略冲突也是可接受的。

但是,Params需要合并4种数据源,尤其是包含Cookies,ServerVariables这二类对象并非与某个页面相关,它们是全局的, 因此冲突的可能性会更大,所以,我认为:如果您要访问Params[],那么,请改成Params.GetValues() ,因为这样才更合适。

Request[]还是Request.Params[] ??

前面说了这么多,我想Request[]和Request.Params[]的差别,这次应该是说清楚了,到此也该给个结论了: 到底选择Request[]还是Request.Params[] ??

我想很多人应该会比较关注这个答案,这里我也想说说我的观点,不过,我要说明一点: 本文的所有文字,都只表示我的个人观点,仅供参考。

我认为:要想清楚地回答这个问题,有必要从二个角度再来观察这二者:常见用法和设计原因。

1. 常见用法: 我一直认为设计这二个集合是为了方便,让我们可以不必区分GET, POST而直接得到所需的用户数据。 如果没有这二个集合,而我们又需要不区分GET,POST时,显然就要自己去实现这类的集合, 而在自己实现时,也极有可能是先尝试访问QueryString, 如果没有,再去找Form ...。看到了吗,这不正是Request[]的实现方式吗? 也正是基于这个前提,遇到前面那种【abc,123】场景时,Request[]得到的结果或许更符合我们的预期。毕竟在获取到结果后, 我们会基于结果做一些判断,比如:name参数可能对应一个数据库的表字段,用它可以找到一个实际数据行, 如果结果是abc或者是123,这时程序都能处理(都有匹配的记录),但来个【abc,123】,这个还真没法处理了。

另一方面,在前面的例子中,我也解释了这并不是Params[]特有的,QueryString, Form都有这样的问题,自然地Request[]也有这个问题, 只是由于Params需要合并4类数据源,让这种冲突的机会更大了

说到这里,有必要再来谈谈前面的几个例子,【abc,123】中,name在QueryString, Form中重复了,显然这属于不合理的设计, 现实情况中,应该是不会产生这类事情的,除非偶然。不过,当偶然的不幸发生时,也正好能体现这二者的差别了。 至于我前面所举的几个例子,虽然在现实中不太可能会出现,但我的意图是在向您展示这些技术的细节差异, 展示一些可能偶然会发生的情况,因此,请不要认为那是个技术误导。

2. 设计原因:让我们再从设计严谨性这个角度来看待这二者的差别,还是拿【abc,123】这个例子来说吧, Request[]这种依次判断的方式,显然会遗漏一些信息,因此,从严谨性这个角度来看,Request[]是不完美的。 毕竟,最终用户会如何以某种想法使用这二个API,没人知道。微软是设计平台的,他们不得不考虑这个问题,不设计这二个集合, 是.net framework的不完善,用错了,就是我们自己的错了。

基于以上观点,我给出我的4点意见:
1. 不建议使用Params[],因为:a. 不希望被偶然情况影响,b. 较高的使用成本。
2. Request[] 使用简单,适合要求不高的场合:示例代码。
3. 如果需要兼顾性能和易用性,可以模仿Request[]自行设计。(通常并不需要访问4个集合)
4. 了解差异,体会细节,有时会发现它还是有利用价值的。

posted on 2011-12-06 21:06  Fish Li  阅读(55350)  评论(65编辑  收藏