如何处理冲突

　　通过前面的一些示例，我们可以看到并非只有Params[]会有冲突，只要类型是NameValueCollection的数据源，都有这个问题。

　　我要再重申一次：QueryString, Form，Param都有这样的冲突问题，只是Param需要合并4种数据源，它将冲突的机率变大了。

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

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

　　现在，还有个现实的问题：QueryString, Form是最常用的数据源，我们要不要这样处理它呢?

　　这的确是个很现实的问题，我认为在回答这个问题前，我们需要分析一下这二个集合出现KEY冲突时是个什么样子的。

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

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

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

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

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

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

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

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

　　① 常见用法: 我一直认为设计这二个集合是为了方便，让我们可以不必区分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中重复了，显然这属于不合理的设计，现实情况中，应该是不会产生这类事情的，除非偶然。不过，当偶然的不幸发生时，也正好能体现这二者的差别了。至于我前面所举的几个例子，虽然在现实中不太可能会出现，但我的意图是在向您展示这些技术的细节差异，展示一些可能偶然会发生的情况，因此，请不要认为那是个技术误导。

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

　　基于以上观点，我给出我的4点意见：

　　不建议使用Params[]，因为：

        不希望被偶然情况影响，b. 较高的使用成本。

　　Request[] 使用简单，适合要求不高的场合：示例代码。

　　如果需要兼顾性能和易用性，可以模仿Request[]自行设计。(通常并不需要访问4个集合)

　　了解差异，体会细节，有时会发现它还是有利用价值的。