一 String和StringBuilder

少量的字串操作不宜採用StringBuilder。
由於string是不可變得物件，對於string的疊加，每次操作都會生成一個新的string物件。所以針對大量string的操作時，我們會採用StringBuilde。但似乎很多人都知道這一點，所以只要字串相加，不管三七二一都用StringBuilder。其實這是個誤區，在這裡要注意”大量”一詞，少量的字串操作用StringBuilder反而得不償失。
比如下面的兩種寫法：
string sql = “insert into table (,,,)”;
sql += ” values (”)”;和
StringBuilder sb = new StringBuilder();
sb.Append(“insert into table (,,,)”);
sb.Append(” values (”)”);
string s = sb.ToString();宜採取第一種寫法。因為只有兩個字串的相加，談不上大量。如果用StringBuilder,最後還需要轉換成string,結果效能反而差一些。

二 慎用異常

由於程式丟擲一個異常，就會建立一個異常物件，然後應用程式會在Catch塊中捕獲該異常，造成效能影響非常大。
比如：
int OrderID;
try
{
OrderID = Convert.ToInt32(this.txtOrderID.Text);
}
catch(Exception e)
{
OrderID = .
}
這樣的程式碼很不合適，造成的效能開銷非常大。應該在客戶端寫js程式碼先去驗證txtOrderID是否符合要求。
三 關於Session, Request

Session:
很多人喜歡用Session來儲存持久物件的值。 但是當你的程式部署在多臺伺服器上做負載均衡時，可能會得不到Session儲存的變數的值。 另外，由於Session是伺服器端的內建物件，每開啟一個Session物件，都在伺服器上佔用一些資源。

Request:
在頁面間傳值取值時，看到很多人都這麼寫程式碼：
string CustomerName = this.Request["txtCustomerName"].ToString();
其實後面的ToSTring()多此一舉。this.Request["...."]本來就是string型別的，不必再去ToString()一下。