剛才讀到這個帖子：
http://www.cnblogs.com/arielyang/archive/2006/01/16/318044.html?Pending=true#Post
作者利用反射的方法，并且結合頁面基類的做法，實現(xiàn)了一種 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;
} // 在上述基礎上，實現(xiàn)幾個常用類型的獲取方法。 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 的實現(xiàn) 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, 的實現(xiàn)
}在我的任何頁面里面，要獲取 querystring 的時候，只要這樣就可以了：
比如我要獲取一個 string:
string name = Util.GetStringSafeFromQueryString(this, "name");if (name.Length > 0) { // 進行正常的處理} else { // 不處理。}獲取 int:
int id = Util.GetInt32SafeFromQueryString(this, "id", 0);
處理 double, float 等等方法完全一樣。
我認為就一個 QueryString 的處理沒必要上升到反射的高度，其實有時候反過來想想，實現(xiàn)的那么復雜也許會喪失一定的靈活性。比如我某個值忽然要改為從 Form 里面得到呢？從 Session 得到呢？這時候就可以比較出哪種做法更適合敏捷的適應需求。
頁面里的 QueryString 的處理，之所以大家都很痛恨手工寫編碼，無非是因為這么幾點：
1. 需要判斷是否 == null 才敢用 .ToString(), 很不爽。稍微不注意，就會拋出異常導致頁面錯誤。
2. 整形，double 等值類型從 QueryString 里面獲取的時候，不知道是否為合法的數(shù)值，因此 Parse 的時候總是要寫重復的處理異常的代碼。
歸納一下，其實，一個頁面用下列語法獲取一個 QueryString 的時候，他得到的是如下東西：
（假設用 string name = Request.QueryString["name"]; 來獲取。）
1. ...test.aspx 得到 null
2. ...test.aspx?name= 得到 ""
3. ...test.aspx?name=abc 得到 "abc"
我認為 1 和 2 的情況實際上從程序處理上來講，是沒有區(qū)別的。因此判斷 null 沒有必要，我們每次都將 null 的值自動讓他轉為 string.Empty 應該是比較安全的做法。
基于上述理由，我覺得如我上面所寫的簡單的工具類，就可以輕量級的解決安全的讀取 QueryString 的問題。
有不對的地方，請大家多多指教。