源代码网整理以下作者利用反射的方法，并且结合页面基类的做法，实现了一种 QueryString 的方便的读取方法。
然而，在我看来，这种做法有些太重了。而我通常采用的做法如下叙述如下。
在一个公共的方法类里面这样写，
public class Util {
private Util() {}
源代码网整理以下 // 从 querystring 集合中安全的取得一个 string. (总是不会有 null，所以叫做 "Safe")
public static string GetStringSafeFromQueryString(Page page, string key) {
string value = page.Request.QueryString[key];
return (value == null) ? string.Empty : value;
}
// 在上述基础上，实现几个常用类型的获取方法。
public static int GetInt32SafeFromQueryString(Page page, string key, int defaultValue) {
string value = GetStringSafeFromQueryString(page, key);
int i = defaultValue;
try {
i = int.Parse(value);
} catch {}
return i;
}
// double 的实现
public static double GetDoubleSafeFromQueryString(Page page,
string key, double defaultValue) {
string value = GetStringSafeFromQueryString(page, key);
double d = defaultValue;
try {
d = double.Parse(value);
} catch {}
return d;
}
// 同理可以写出 float, 的实现
}
软件开发网 www.mscto.com
源代码网整理以下在我的任何页面里面，要获取 querystring 的时候，只要这样就可以了：
比如我要获取一个 string:
string name = Util.GetStringSafeFromQueryString(this, "name");
if (name.Length > 0) {
// 进行正常的处理
} else {
// 不处理。
}
源代码网整理以下获取 int:
int id = Util.GetInt32SafeFromQueryString(this, "id", 0);
源代码网整理以下
处理 double, float 等等方法完全一样。
源代码网整理以下我认为就一个 QueryString 的处理没必要上升到反射的高度，其实有时候反过来想想，实现的那么复杂也许会丧失一定的灵活性。比如我某个值忽然要改为从 Form 里面得到呢？从 Session 得到呢？这时候就可以比较出哪种做法更适合敏捷的适应需求。
源代码网整理以下页面里的 QueryString 的处理，之所以大家都很痛恨手工写编码，无非是因为这么几点：
1. 需要判断是否 == null 才敢用 .ToString(), 很不爽。稍微不注意，就会抛出异常导致页面错误。
2. 整形，double 等值类型从 QueryString 里面获取的时候，不知道是否为合法的数值，因此 Parse 的时候总是要写重复的处理异常的代码。
源代码网整理以下归纳一下，其实，一个页面用下列语法获取一个 QueryString 的时候，他得到的是如下东西：
（假设用 string name = Request.QueryString["name"]; 来获取。）
1. ...test.aspx 得到 null
2. ...test.aspx?name= 得到 ""
3. ...test.aspx?name=abc 得到 "abc"
源代码网整理以下我认为 1 和 2 的情况实际上从程序处理上来讲，是没有区别的。因此判断 null 没有必要，我们每次都将 null 的值自动让他转为 string.Empty 应该是比较安全的做法。
源代码网整理以下基于上述理由，我觉得如我上面所写的简单的工具类，就可以轻量级的解决安全的读取 QueryString 的问题。
