其實在以前還沒有使用 LINQ to SQL 或是 ADO.NET Entity Framework 於專案開發的時候，就已經會使用 Code Snippet 來讓寫程式的速度加快，w因為資料存取層或是商業邏輯層的 CRUD（Create, Read, Update, Delete）會有很多程式是結構雷同的，而只有細節的地方有些變化，畢竟有些程式無法從程式中去抽離出來做為獨立方法或是元件，所以會把這些結構雷同的程式給抽出來做成 Code Snippet，w如此一來在寫程式的時候就可以直接使用 Code Snippet 來減少輸入程式的時間，二來也可以讓程式結構達到一致性。
一般來說專案的資料庫如果是使用 Oracle，大部分的狀況下存取資料庫都會是使用 System.Data.OracleClient，但是在兩年多前微軟就已經宣布 System.Data.OracleClient 在 .NET 4.0 雖然還會支援這個型別，但是在未來的 .NET Framework 版本將會移除，在 .NET 4.0 之中會被標記為「Deprecated （已過時的）」
http://blogs.msdn.com/b/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx
黑暗執行緒 - System.Data.OracleClient將走入歷史
http://blog.darkthread.net/post-2010-05-14-bye-ado-net-oracleclient.aspx
雖然說現階段還是可以繼續使用 System.Data.OracleClient 於專案中而且編譯也沒有問題，但是就如黑暗大所說的，還是改用 Oracle 官方所提供的「ODP.NET from Oracle」，早期 Enterprise Library DataAccess Application Block (DAAB) 並無支援使用 ODP.NET，一直到了 EntLib 4.1 之後才有支援使用 ODP.NET，接下來本篇將會說明如何讓 Enterprise Library 5.0 DAAB 使用 ODP.NET 的設定方式。
經過前篇介紹Firefox, IE, Opera瀏覽器的開發者工具後，接下來的這一篇將要一起介紹兩個瀏覽器：
Google Chrome, Safari
為什麼要把這兩個瀏覽器給擺在同一篇來做介紹呢？一定有人會有這樣的疑問，
簡單說，這兩種瀏覽器的核心都是用同一種引擎「WebKit」，雖然都是用同一種引擎但還是有不同的地方。
前面介紹過Firefox與IE的開發者工具後，接下來介紹另一個比較少人會使用的瀏覽器「Opera」，
雖然說Opera列名在五個主要的瀏覽器中，但Opera卻是最少人使用的一個，
其實Opera的執行速度與其他效能的表現上卻是一點也不遜色，比起其他比較多人使用的瀏覽器更是相當出色。
接下來這一篇就簡單的介紹Opera的開發者工具。
小弟從事網站程式的開發已有一段時間，前些年的網站技術並沒有太多AJAX的技術，
而且前端的程式也多半被認為只是拿來做效果或是搞花樣的不起眼小東西，
那時候前端的JavaScript程式最常拿來做什麼…跑馬燈、訊息提示、多層下啦選單、螢幕效果等，
了不起更進階就會使用到網頁表單上的輸入檢查、金額數量計算，
然而網站開發時至今日，所謂的網站程式設計已經不單純只是Server端程式而已，也包含了前端的JavaScript程式。
現在越來越多人採用ASP.NET MVC技術來開發網站，就會大量的使用到前端的JavaScript程式設計，
非.NET技術的開發人員或許會覺得這沒有什麼好稀奇的，但 .NET領域的開發人員大部分仍舊採用ASP.NET WebForm，
這一部分的開發人員很多人對於AJAX的想法與觀念就純粹就只是把一堆伺服器控制項丟到UpdatePanel中，
更進階的開發人員會再去細分一個頁面會去拆成多個部分去放置多個UpdatePanel，
但是大量使用UpdatePanel的情況下，是這些ASP.NET WebForm開發人員還是對於前端程式還是無法掌握與進一步應用，
因為ASP.NET WebForm的PostBack機制與與網頁生命週期的難以捉摸，前端JavaScript終究還是被大多人視為「做效果」。
上個專案是採用ASP.NET MVC來開發，前端的jQuery程式的應用就相當的多，其程式行數量與複雜度就與後端程式相當，
專案團隊的成員有四分之三的人不熟悉jQuery的操作，因為對於jQuery不熟悉也就對於如何去使用工具偵錯就更不得而知，
有個成員對於前端程式的偵錯就是直接使用 alert() 的方式，讓前端程式執行時再把要追蹤偵錯的訊息給 alert 出來，
這樣的作法相信很多人直到現在還是這樣做（而且樂此不疲？！），這樣的做法也是可以啦……
但是要偵錯時就要出現一堆的 alert 然後再一次又一次的按下 alert 的確定按鍵讓視窗消失後再進行下一個 alert ……
而直到現在一定還有一堆人都不知道 IE 瀏覽器有開發者工具可以幫助更方便的做這些前端的偵錯工作。
我必須說，懂得掌握工具的使用就能更有效率的進行開發，所以就整理了一下目前五個主要瀏覽器的開發者工具，
Firefox、IE、Chrome、Safari、Opera
介紹這些瀏覽器的開發者工具要怎麼把它們從瀏覽器中叫出來，並且簡單介紹如何的使用。
現在很多專案都已經使用Linq to SQL 或是 ADO.NET Entity Framework或者是其他的ORM Framework來做為專案中物件與資料存取對應的Solution，
就單純的以.NET Framework所推出的Linq to SQL 與ADO.NET Entity Framework來說，在資料庫中將各個Table的關連性給定義好之後，
到了程式設計階段時，使用工具產生Linq to SQL或是EF的定義模型時就會一併定義對應物件的關聯性，
這樣一來有關連的物件就可以取得其關連物件的物件集合，而且這個關連物件集合讀取就是以延遲載入的方式來使用。
以往在開發 ASP.NET WebForm 專案時，如果專案需求是有編輯 HTML 圖文資料時，大多都會選擇使用 FCKEditor，FCKEditor 是個相當不錯的 HTML 編輯器，能夠符合許多情境的需求，然而 FCKEditor 的開發已經停止，轉而開發 CKEditor，CKEditor 是將原本的 FCKEditor 給全部重新寫過，雖然大致上的設定還是與原本的FCKEditor 相去不遠，但卻有著很大的不同，我在 ASP.NET MVC 3 專案上還沒有對 CKEditor 做過整合，所以此次就練習在 ASP.NET MVC 3 專案上整合 CKEditor 的功能，使用 NuGet 來取得 CKEditor，並且試著用不同的方式在前端與後端的傳值上做些不同的變化。
之前我們介紹了 LINQ to JavaScript (JSLINQ)的基本使用方式，而我們所下載的JSLINQ是2009年所發佈的版本，
在JSLINQ的Codeplex的網站上作者所簽入Source Code離最近一次的日期是 2010-11-13，
所以我們就來使用這Source Code裡最新版本的函式庫，新版本的函式庫中有新增了幾個function，
而我們就來看看這些新的function以及進行幾個進階操作。
接觸並且使用 Enterprise Library （以下簡稱為 EntLib ）在專案中開發已經有很長一段時間了，在 Linq to SQL, ADO.NET Entity Framework 出現之前的對資料庫存取都會使用 EntLib 的 Data Access Application Block (DAAB)，而不是使用既有的 ADO.NET 操作，使用 DAAB 除了可以讓程式碼撰寫的行數減少一些之外，DAAB 對於 ADO.NET的操作也做了優化，所以使用 DAAB 做資料存取的動作是會比使用原生 ADO.NET 操作方式來得方便，但是不要認為說使用DAAB就可以不用管ADO.NET囉！因為DAAB的內容都還是繞著ADO.NET操作上打轉，DAAB把我們在使用ADO.NET操作的方法都做了包裝。
原本打算要寫一系列有關 Enterprise Library 的文章，但是一直沒有時間好好的規劃撰寫的方向與架構，而且這兩三年來在專案開發上也都是使用 Linq To SQL 或是 ADO.NET Entity Framework 來做為資料存取的 solution，以致於很少有機會再去接觸以及使用 EntLib ……
而最近一個專案的關係，讓我又重拾 EntLib 的使用，因為這個專案使用的是 Oracle 資料庫，原本打算使用 ODAC for Entity Framework，但是……客戶的技術思維還停留在 .NET 2.0 的時代，不要說什麼是 ORM，連什麼叫做LINQ都不知道了，客戶為了日後他們自己維護的方便，所以堅持使用傳統的ADO.NET方式來做為資料存取的解決方案，也就是因為這樣讓我決定使用 EntLib 的 DAAB 來操作對 Oracle 資料庫的存取。
在上一篇「前端處理JSON資料 - 轉為陣列以及簡單篩選」說明了如何使用 $.grep() 方法在前端程式中去篩選陣列中的資料，
但是如果要處理的篩選條件是比較複雜時，使用 $.grep() 依然是可行，但總會任人覺得不是那麼方便，
尤其是寫 C# 的開發者在 .NET Framework 3.5 之後對於集合資料的操作已經熟悉並且習慣了 LINQ 語法，
而在前端程式中卻沒有這樣方便的處理方式，在處理集合資料時就會覺得綁手綁腳的，
其實這情形早已經有人做了一個解決方案，「LINQ to JavaScript」( 簡稱為 JSLINQ )，
在2009年的時候在MSDN學習園地的CodePlex教學中就有對這個函式庫做介紹「LINQ to JavaScript: 在 JavsScript 也可以用 LINQ」
接下來就來說明一下使用的方式。
寫ASP.NET MVC的時候，前端與後端的資料處理上常常都會使用到JSON格式的資料，
頁面上的資料呈現與處理都可以直接使用前端程式來執行，而後端就只需要去做產出資料與接收資料的工作，
而前端程式中要去處理JSON資料時，我比較常用的就是把它轉為物件陣列然後再做進階的處理，
以下就簡單記錄一下這些處理的操作方式。
使用NLog的最大一個功能就是要去捕捉並且記錄下發生Exception的訊息與內容，
而在有關「使用NLog - Advanced .NET Logging 」系列的文章中都有說明到如何記錄以及記錄哪些資料，
NLog有提供很多的Layout Renderer可以使用，而Exception Layout Renderer更是要好好的來仔細整理一下，
前面花了三篇的篇幅從安裝Oracle XE、使用管理Oracle XE以及將Northwind資料庫安裝到Oracle XE中，這些的動作都是為了在開發.NET專案時去使用Entity Framework對Oracle資料庫進行資料存取的操作，而最重要的關鍵就在於 ODAC for Microsoft Entity Framework and LINQ to Entities。
Oracle總算是推出了對於Entity Framework的Provider，雖然直到現在還是Beta版，但至少也是一項的選擇，不然以往使用Oracle資料庫的專案，無法使用LINQ to Entities來操作，總覺得做Oracle的專案真的很麻煩，雖然說有商業套件有提供Provider讓開發者可以透過Entity Framework去對Oracle做存取，但是商業套件…尤其又是存取Oracle，那麼就是需要花一大筆錢才能夠獲得解決，當公司擺明就是不想花錢買授權的時候，就是我們開發者頭痛的時候了，接下來就看看這個 ODAC for Microsoft Entity Framework and LINQ to Entities…
我們一開始接觸微軟的 MS SQL Server 時，最先接觸到的範例資料庫就是 Northwind，而有很多的文章範例都是使用 Northwind 為資料來進行各種的功能操作，而既然之前「ASP.NET MVC + Oracle 11g XE + Entity Framework. Part 2」的文章內容中已經把 Oracle 11g XE 給安裝以及建立好要使用的 Tablespace，接下來的動作當然就是把 Northwind 的 Table 與資料給安裝到 Oracle 11g XE。
使用及管理Oracle 11g Express Edition，使用Oracle SQL Developer, Navicat Lite
資料庫裝好之後就是要來用，但是 Oracle 11g XE 所預設的管理介面看起來實在太過於陽春了，又或許應該說，我不會用這個管理介面來管理安裝好的資料庫，因為 Oracl XE 資料庫的安裝就如同 MS SQL Express 安裝一樣，安裝好只是把資料庫的 Instance 裝好而已，要一個 GUI 的管理工具就必須另外安裝，MS SQL Server Express 就有一個「MS SQL Server Management Studio Express」的GUI工具，而Oracle資料庫則是有個官方版的「Oracle SQL Developer」，另外也有個相當好用的第三方管理工具「Navicat Lite」，上面兩種在使用後的感覺是，Oracle SQL Developer 比較佔資源，而Navicat Lite則是比較輕巧些。
使用 .NET 開發的專案雖然大多數所搭配的資料庫都是 MS SQL Server，但還是會碰到會使用到 Oracle 資料庫的時候，通常這樣類型的專案於開發時應該都會配置一個與正式環境一樣的 Oracle 測試資料庫，但如果在一些特殊的狀況下：多人開發、測試資料庫只能測試用而不能開發用 … etc
這個時候不會建議在程式設計師的開發環境下去安裝 Oracle 資料庫，畢竟一台電腦安裝太多的軟體難免會出現例外狀況，所以在這個時候會比較建議開發者去準備另外一台電腦來安裝 Oracle 資料庫，或者是開發者電腦環境允許的情況下（記憶體 > 4GB）就十分建議建立一個虛擬機器，然後在 VM 上安裝 Oracle 資料庫。
基本上計算日期的差距可以在後端的程式裡或是在資料庫中就可以解決，
但有些時候資料只會在前端出現而未後送到Server Side，或是說不想增加資料庫或是Server Side的負載，
所以就會將這種單純的顯示日期時間差距的計算工作給放到前端去做，
這樣做其實也是有好處的，好處就是讓Client Side去做這類瑣碎的計算，
因為不牽涉到太複雜的邏輯計算，也算是分擔後端的壓力。
所以接下來就會介紹三種方式來達成在Client Side去計算日期時間差距的功能。
上一篇「ASP.NET MVC, JSON資料的日期轉換與格式化 1」說明了後端序列化的JSON日期資料要如何轉換以及格式化，
然而我們在後端所用的序列化JSON是直接使用ASP.NET MVC的預設內部方法，也就是用JavascriptSerializer來做序列化，
而之前有好幾篇文章也有說明到各種的在後端序列化的方式，
所以這一篇我們就來看看各種的序列化方式的JSON日期轉換與格式化。
前面有好幾篇文章是說明在後端的程式中要如何去對物件資料序列化為JSON，
而物件資料序列化為JSON之後就是要傳給前端去使用，然而JSON資料卻會有個小小的問題存在，
JSON規格中沒有對日期時間的型別去做定義，在 .NET 環境下的日期時間資料在序列化之後卻會有個特別的表示方法，
讓使用者知道某個欄位的資料是個日期型別，
如果是直接已JsonResult的Json方法做資料的序列化，則日期型別的資料會是以下格式：
\/Date(1316747376403)\/如果是用Json.NET的JsonConvert.SerializeObject()來序列化，則日期型別的資料會是以下格式：
\/Date(1316747376403+0800)\/
除非是在後端的程式中就已經對日期型別的資料去做處理，不然傳到前端的日期資料都還是要再做個處理。
如果使用TagBuilder的地方是在ASP.NET MVC2的網站專案下，是可以直接使用TagBuilder，
而要是將有使用到TagBuilder的類別、Helper的程式放在另外的類別庫專案，也只需要去加入System.Web.MVC的參考，
在ASP.NET MVC 2 裡，TagBuilder的命名空間是「System.Web.Mvc」而組件是「System.Web.Mvc.dll」
但是到了ASP.NET MVC 3 後就有了改變。
接續「ASP.NET MVC + JSON 自定義JsonResult 1」的內容，
上一篇文章的最後有說，Json.NET所提供的 JsonNetResult類別並不是很適合拿來使用，
而在「使用Entity Framework 將物件轉為JSON時遇到循環參考錯誤 3」裡面，我們也建立了兩個JavaScriptConverter類別，
所以我們就自己來建立一個自己定義的JsonResult，並且使用之前所建立EFJavaScriptSerializer，
這個 EFJavaScriptSerializer 可以分別依據狀況使用 EFSimpleJavaScriptConverter 或 EFJavaScriptConverter…
在「使用Entity Framework 將物件轉為JSON時遇到循環參考錯誤 1」裡面有提到，
如果把EF取出的物件不做任何處理然後在JsonResult中直接使用 Json()方法傳回，會出現「循環參考」的錯誤，
而文章中有提到說可以使用Json.NET所提供的 JsonConvert.SerializeObject()方法來回傳Json資料，
但是必須要使用ActionResult的類別來回傳，而且為了讓Content-Type正確，也需要指定Content-Type，如以下的程式：
public ActionResult Product(int? id)
{ if (!id.HasValue) {Dictionary<string, string> jo = new Dictionary<string, string>();
jo.Add("Msg", "請輸入產品ID編號.");
return Content(JsonConvert.SerializeObject(jo), "application/json");
}
else { ProductService service = new ProductService();var product = service.Single(id.Value);
return Content(JsonConvert.SerializeObject(product), "application/json");
}
}
使用了Json.NET來做為序列化JSON資料的工具，而Json.NET的官網上面也有提供了一個JsonNetResult的類別，
這樣一來在Action就不用再多一個動作去指定使用JsonConvert.Serialize() 方法來序列化資料，
另外也不用使用回傳類別ActionResult，也不用再去指定Content-Type。
接續「使用Entity Framework 將物件轉為JSON時遇到循環參考錯誤 2」
上一篇是說明如何去修改Edmx的屬性「消極式載入已啟用」設定
以及在不修改Edmx的屬性「消極式載入已啟用」的情況下於程式中將LazyLoadingEnable設定為false，
透過這些的修改方式讓物件於序列化為JSON時不去包含或是不載入關連的物件資料。
而這一篇就來看看使用自定義的JavaScriptConverter類別，在不修改上述兩項設定的情形下，
如何做到只序列化物件本身的資料以及序列化物件本身以及其關連的物件資料。
接續「使用Entity Framework 將物件轉為JSON時遇到循環參考錯誤 1」
public ActionResult Product(int? id)
{ if (!id.HasValue) {Dictionary<string, string> jo = new Dictionary<string, string>();
jo.Add("Msg", "請輸入產品ID編號.");
return Content(JsonConvert.SerializeObject(jo), "application/json");
}
else { ProductService service = new ProductService();var product = service.Single(id.Value);
var result = new {ProductID = product.ProductID,
ProductName = product.ProductName,
SupplierID = product.SupplierID,
CategoryID = product.CategoryID,
CategoryName = product.Category.CategoryName,
QuantityPerUnit = product.QuantityPerUnit,
UnitPrice = product.UnitPrice,
UnitsInStock = product.UnitsInStock,
UnitsOnOrder = product.UnitsOnOrder,
ReorderLevel = product.ReorderLevel
};
return Content(JsonConvert.SerializeObject(result), "application/json");
}
}
上面的程式是把Product物件取出後，再去指定要序列化為JSON時所要用的欄位，
但如果每次要對物件做序列化時都要這樣手動去指定也算是一件蠻累人的事情，
尤其是欄位多的時候以及一個物件會在多個地方去做序列化為JSON的操作時，一再重複這樣的事情就會覺得煩。
在ASP.NET MVC的Controller中會經常使用到JSON，通常都是前後端的資料處理，
後端產生物件資料後再轉為JSON傳到前端做AJAX的處理，而後端也會接收前端所傳來的JSON資料，
而ASP.NET MVC的Controller有很多的傳回類別，其中一個有關JSON的就是「JsonResult」，
JsonResult類別
http://msdn.microsoft.com/zh-tw/library/system.web.mvc.jsonresult.aspx
表示用來將JSON格式之內容傳送至回應的類別。（繼承自抽象類別ActionResult）
如果要經由Json(object, JsonRequestBehavior.AllowGet)的方法去傳回JsonResult，結構簡單的物件是不會發生問題的，
例如：
public JsonResult Product(int? id)
{ if (!id.HasValue) {Dictionary<string, string> jo = new Dictionary<string, string>();
jo.Add("Msg", "請輸入產品ID編號.");
return Json(jo, JsonRequestBehavior.AllowGet);}
else { ProductService service = new ProductService();var product = service.Single(id.Value);
var result = new { ID = product.ProductID,
Name = product.ProductName,
CategoryID = product.CategoryID
};
return Json(result, JsonRequestBehavior.AllowGet);}
}
結果：
但如果我們所取得的物件資料不會再去做物件欄位的選擇，而是直接將整個物件放到Json(object)方法中，
而Model的資料模型是使用ASO.NET Entity Framework，各個資料表都有設定關連時，這個時候就很容易出現以下的錯誤：
是的，出現了循環參考的錯誤！怎解呢？
因為有人問起，再加上自己以往沒有做過，所以就來試試看，其實這一題只是將以往的作法給稍微改變就可以了，
以往很多人使用Web Service的方式都是直接在Web專案中加入服務參考，
但是這樣會有幾個問題就是：
如果這個Web Service會在多個專案中去使用到的話，那麼每個專案都要做同樣的動作…
如果使用Web Service還會再去封裝一些方法，每個專案去加入服務參考後還要再去複製貼上已經做好的方法，這種複製貼上不是正確的寫程式方式…
所以接下來就看看這練習題要如何做。
透過Mail target將Log訊息寄發到指定的Email中
在之前介紹的ELMAH文章中「ASP.NET MVC + ELMAH 監控並記錄你的網站錯誤資訊 3」有介紹到，當系統發生了 Exception 狀況時，就會寄發通知信件到指定的 Email 中，雖然說我們可以在某些特定的 Exception 發生時在去寄發通知（詳見「ELMAH - 自訂錯誤通知郵件的設定(於特定Exception)」），但是只依據特定的 Exception 種類來通知，光是設定就很累人，因為Exception的種類有很多，並非我們可以完全掌握住。
最好的方式就是在程式之中，於捕捉 Exception 的程式碼去使用 NLog 記錄Exception訊息，並且做好 Exception 的Log 分級，然後在 NLog.Config 中再去做設定，當 Log 於什麼樣的等級發生時就去使用 Mail target 寄發通知給特定人員的 Email 信箱中。
接下來就會說明如何設定並透過Mail Target 將Log訊息寄發給特定人員。
雖然NLog提供的Layout Renderers已經相當多種了，
而且如果要記錄ASP.NET Request ServerVariable的資料，可以使用：${aspnet-request : serverVariable=String} ，
但是Request.ServerVariable有相當多種，除非你相當有耐心，不然一個一個變數去加入NLog.Config中也是一件累人的事情，
所以如果可以像ELMAH一般，預設就是把所有的Request.ServerVariable給記錄下來，
我們可以擴展自定義的Layout Renderer來記錄這所有的Request.ServerVariable資料。
在NLog中可以透過${aspnet-request}的layout來取得用戶端所送出的資料，包含有：
cookie, serverVariable, queryString, item, form
參考連結：NLog Documentation - Aspnet-request layout renderer
而其中最常用到的是serverVariable，這是用來取得Web伺服器的環境變數，而伺服器環境變數有相當多，
如以下所示：
ALL_HTTP：傳送到客戶端的所有HTTP header資料
ALL_RAW：傳送到客戶端的所有資料(以raw的資料格式)
APPL_MD_PATH：傳回伺服端的metabase路徑
APPL_PHYSICAL_PATH：將APPL_MD_PATH轉換成為實際的路徑傳回
AUTH_PASSWORD：傳回客戶端使用者在確認對話框中所輸入的密碼
AUTH_TYPE：傳回客戶端認證的方法
AUTH_USER：傳回客戶端確認在確認對話框中所輸入的使用者名稱
CONTENT_LENGTH：傳回content的資料長度
CONTENT_TYPE：傳回客戶端文件傳送的型態，如GET或POST等...
GATEWAY_INTERFACE：傳回伺服端的CGI版本
HTTP_：傳回使用者自建的HTTP Header資料
LOCAL_ADDR：傳回伺服端電腦的IP位址
LOGON_USER：傳回登錄Windows NT的使用者資訊
PATH_INFO：取得目前網頁的虛擬路徑
PATH_TRANSLATED： 目前執行的ASP程式，位於伺服端的真實路徑
QUERY_STRING：傳回在HTTP://後以?所傳遞的參數資料REMOTE_ADDR：遠端主機的IP位址
REMOTE_HOST：遠端主機的名稱
REMOTE_USER：遠端的使用者名稱
REQUEST_METHOD：傳回HTTP的請求方式，如GET或POST等...
SCRIPT_NAME：被執行的ASP檔案完整的虛擬路徑
SERVER_NAME：傳回網頁伺服端的電腦名稱，DNS或IP位址
SERVER_PORT：伺服端HTTP的埠(Port)
SERVER_PORT_SECURE：傳回客戶端是否指定安全的埠，是則為1，否為0
SERVER_PROTOCOL：取得HTTP的版本
SERVER_SOFTWARE：取得網頁伺服器的名稱與版本
URL：取得目前網頁虛擬路徑的儲存位址
參考連結：MSDN - IIS Server Variables
然而我在NLog.Config中去指定取得一個serverVariable，指定取得目前網頁的網址：
<parameter name="@url" layout="${aspnet-request:serverVariable=url}" />
所出現的錯誤：
嘗試建立型別 'Test.Web.Controllers.HomeController' 的控制器時發生錯誤。請確認此控制器是否有無參數公用建構函式。再來看看ELMAH所記錄到的詳細錯誤資訊：
type="System.ArgumentException"message="LayoutRenderer cannot be found: 'aspnet-request'"source="NLog"detail="System.InvalidOperationException: 嘗試建立型別 'Test.Web.Controllers.HomeController' 的控制器時發生錯誤。請確認此控制器是否有無參數公用建構函式。
看來這是NLog設定發生問題而出現的錯誤…
在上一篇文章「使用NLog - Advanced .NET Logging (1)」裡面，我們是把Log資料給存放到文字檔中，
文章範例程式中的NLog.Config，有兩個target type是使用了File而另一個是使用EventLog，
其實NLog的taget有預設提供了多達25種，但不見得每個都有機會去使用到，
而且你還可以依據NLog提供的API，讓你可以建立你自己想要的target，
除了已經介紹的File與EventLog外，最常用的也是最多人想要使用的就是「Database」。
以下就將會介紹如何修改target設定，把Log資料存放到資料庫中。
在前面的幾篇文章已經介紹過如何在網站中使用 ELMAH 來記錄與追蹤各種的訊息與錯誤，ELMAH 已經可以達到Logging 的功能要求，但是如果需要對各種記錄去做分級處理的話，使用 ELMAH 就不是那麼方便，一般而言，網站中最好除了使用 ELMAH 外，最好再使用另一套 Logging 的套件，ELMAH 是用來作為日誌記錄，主要工作是捕捉 UnHandler Exception（未處理的異常），所以有處理的（try…catch..）異常就無法捕捉。
NLog就是讓我們可以在程式裡去處理異常時，給予不同的等級後，NLog再依據使用者所定義各等級的不同處理方式做後續的操作，看是要Email通知還是記錄在系統的Event Log還是多種方式傳送訊息等等，一且都可以讓使用者去依照需求而定義。
NLog的功能相當齊全，設定也相當簡單、容易上手，所以接下來將會介紹如何在網站專案中安裝與設定NLog。
因為開發的專案是一個有關會計系統的網站系統，所以頁面上的輸入欄位(TextBox)會相當的多，
而使用者輸入數字後通常不會再去抽出左手去按下Tab鍵讓輸入框的focus移到下一個，
通常使用者都是左手控制傳票或是指向要輸入數字的地方，而右手就是在鍵盤右方的數字鍵那邊一直輸入，
當輸入完一個欄位後就是直接按下數字鍵的Enter鍵，讓輸入框的focus移到下一個。
其實這一點都不是很難，而且網路上也有人針對此功能做出了相關的jQuery Plugin套件，
這裡就做個介紹與使用的方式。
如果開發的專案式屬於會計系統之類的，常常會有個基本的功能要求，
那就是TextBox所輸入的金額數字必須要能夠轉換為千分位，
所謂千分位就是每三位數就要用「，」逗號分隔，我想這應該每個人都知道的基本常識，
於是在開發專案的時候就參考了幾個網路上的Script之後，就寫了幾個function用來處理千分的需求。
其實glimpse可以結合ELMAH，讓ELMAH所記錄到的錯誤訊息於glimpse中顯示，在系統的登入認證後，只要啟用glimpse就可以去看ELMAH的紀錄資料，不必再另外進入ELMAH，接下來介紹如何透過NuGet安裝Elmah plugin for Glimpse以及部分的修改設定。
請記得，你的網站必須示已經安裝了 ELMAH 以及 Glimpse…
在「ASP.NET MVC + ELMAH 監控並記錄你的網站錯誤資訊 3」這篇文章中介紹了ELMAH寄發郵件通知，
也說明了如何不去寄發特定Http StatuCode錯誤的信件通知，
但是在Web.Config的elmah Section的errorMail設定中，已經把寄發信件通知的Subject給統一處理了，
這樣一來就無法分辨寄來的錯誤通知的差異性，
因為有些錯誤是必須要能夠設定重要性，而且也需要在信件主旨中可以馬上辨識以快速處理，
所以接下來就是說明一下對於特定的Exception要如何去設定個別的見信重要性與信件主旨。
上篇文章「ASP.NET MVC 使用Glimpse監測網站的一舉一動 1」，說明了什麼是Glimpse以及如何透過NuGet安裝，另外也簡短的說明Glimpse的內容與如何使用Trace功能，然而與ELMAH所遇到的問題是一樣的，那就是預設安裝後，都是可以匿名瀏覽，對於網站的安全性來說是個相當大的威脅，尤其是Glimpse的Config，會把Web.Config的所有資訊都完整呈現，所以這一篇文章就要來說明如何讓Glimpse在登入後才可以使用。
之前有介紹一個可以即時監測網戰後端每個處理的處理時間的監測套件「MiniProfiler」，如果說要連帶要監測前後端的每一像細節的話，那麼MiniProfiler可能就沒有辦法，而且MiniProfiler是無法遠端做監測的動作，MiniProfiler只能夠監測本地端的動作，所以MiniProfier比較適合開發期間使用。
而在開發ASP.NET WebFrom的時後，如果想要追蹤每個頁面的執行狀況與效能的話，其實是可以使用「Trace」功能，如此一來就可以在每個頁面的下方顯示頁面執行時的完整詳細資訊，包括前端傳送的Http Request、所有的Session、Cookie等，對於開發時期來說，這些資訊可以幫助我們在除錯時候可以掌握確切的資訊。
然而系統上線之後，Trace功能勢必要關閉，而單靠ELMAH記錄錯誤訊息也無法完全掌握，因為有的時候執行正常並不表示功能正常，例如執行時間過慢、路徑錯誤等，所以接下來就來介紹「Glimpse」，除了具有Trace的功能外，也可以結合Forms Authentication的登入認證，讓我們在系統上線之後，一樣可以即時讓開發人員追蹤頁面執行的各項資訊。
前面幾篇文章有關 ELMAH 的文章都是把錯誤訊息記錄在「~/App_Data/Elmah.Errors」下，然後一個錯誤就是一個 XML 檔案，這樣做的原因是可以避免因為資料庫無法連線時而造成錯誤訊息無法記錄的意外，而本篇文章將會說明如何將 ELMAH 的錯誤訊息的儲存媒體改為使用 SQL Server。
前兩篇有關於ELMAH的文章中介紹了了如何安裝以及如何做權限設定的修改，這一篇就來說明一下如何讓ELMAH在記錄錯誤也同時發出Email通知特定的人員，畢竟有錯誤發生時，如果可以即時的將訊息通知給特定人員(WebMaster or PM or Developer)，對於錯誤狀況的掌握會更加迅速（對於開發人員來說，比客戶早一點知道總是比較好吧）。
上一篇文章「ASP.NET MVC + ELMAH 監控並記錄你的網站錯誤資訊 1」有遇到一個問題，那就是原先ELMAH所預設的設定會讓任何人都可以看到ELMAH記錄，對於網路的安全性就有極大的危險，因為錯誤記錄都記錄了許多的資訊，除了客戶資訊外也包含了Server的環境資訊，甚至於錯誤的程式碼位置'、輸入的機密資料等，怎麼可以讓任何人說進來就進來呢？
所以有些安全性的設定還是要記得去修改、去設定，免得讓有心人竊取資料或是毀損資料。
網站上線或是還在開發、測試階段時對於難以捉摸的錯誤總是讓開發人員頭痛不已，如果是在開發環境裡，還容易抓到錯誤，一旦上了測試機或是正式機之後，錯誤的發生就無法立即掌握，尤其是當客戶在測試的時候往往遇到錯誤就只會通知開發人員說「你的程式有 BUG！」，但是要問客戶說這些錯誤是怎麼發生的時候，客戶通常是說不清楚，甚至有的客戶明明操作錯誤或是輸入錯誤的資料而引發錯誤，但也不會老實跟開發人員說出實情，而如果可以任何時候都監控網站並且當錯誤發生的時候將當下的資訊給記錄下來的話，對於開發人員甚至是對於系統的功能完整、安全防護、減少 BUG 數等等都是一件好事。
網路上有很多種監控以及記錄的工具，然而眾多的工具、套件中最容易上手的應該就是 ELMAH 了，而且最重要的是，ELMAH 有提供 DashBoard 可以查看記錄的訊息，另外也可以透過遠端的方式去查看記錄，如此一來就可以更加容易掌握網站的一舉一動了(安全機制還是要先做好)，就讓我們來看看如何在你的 ASP.NET MVC 3 網站中使用ELMAH 來監控並記錄錯誤訊息。
有時候jQuery寫久了，只要在執行的時候沒有出現錯誤或是執行結果正確，往往都會覺得這麼寫是OK的，
然而就像寫C#程式一樣，有時候有些寫法會帶來更好的效能或是更能夠發揮語言的特性，
但是通常都要到Code Review時或是出現效能問題時才會去注意到然後去改善，
前端語言因為缺乏所謂的編譯檢查，所以只能等到去執行時才能夠檢查出來，
而且還可能有更多位察覺的地方隱藏其中，如果有個工具可以在必要的時候時時提供改善建議不是很好嗎?
其實一直很想寫下這一篇，但是又發現到其實很多人都會用Firefox + Firebug 的組核對前端網頁進行偵錯，
應該說，從事網頁設計、開發的從業人員都應該會用才對，
但是… 在我目前工作的公司裡，還真的有很多人不用、不會用、甚至是不知道有這樣的工具。
更有些人對於前端語言的偵錯方式還是使用那一套 alert() 大法，
就是在程式之中要偵錯的地方就是狂下 alert()，把要顯示的訊息給alert出來，
這方法不能說不好，但是偵錯的時候就去改變原始碼，然後修改完再去一一的把alert給移除，
萬一遺漏了一些的話，那麼就會看到上線的網頁會有些地方就出現不該出現的alert訊息視窗啦，使用者就認為這是BUG！
Firebug是個相當優異的前端偵錯工具，而且還有很多可以掛載在上面的套件，整合在Firebug之中，讓偵錯更加方便，
所以本篇不會是一篇教你如何使用Firebug來偵錯的Step教學，而是一篇介紹如何應用Firebug與Firebug外掛讓偵錯更加便利。
會介紹以下幾個Firebug的外掛工具：
這是Firefox因為你所瀏覽的網頁正在執行一些複雜且需長時間的前端程式，更有可能是執行中的程式已經失去控制，
或者是有些安裝於 Firefox 的套件而導致這樣的情況發生，例如：Firebug…
雖然說，上面出現的那個視窗可以勾選「下次不要詢問」，但是往往還是會時常出來跟你打招呼…
在前端使用JavaScript ( jQuery ) 時，有時候在某些操作上不是那麼方便，
畢竟後端C#程式寫久了，而且也很習慣Visual Studio的智能顯示(IntelliSense)，
雖然說在VS2008後一直到目前的VS2010對於JavaScript( jQuery ) 的支援越來越好，也可以使用智能顯示，
但還是有些基本的方法還是要手動去寫程式擴充，
所以這邊就整理了三個有關在JavaScript對於String的屬性的擴充：
startsWith
endsWith
contains
問題：
開始日期：2011/09/28
結束日期：2011/12/31
請取出 "每一個月第4週的星期二" 的日期。
其實這一題是延續「練習題：於指定的日期區間中取出符合指定DayOfWeek的日期」，
看起來好像蠻簡單的，但是這裡頭也碰到了幾個基本的日期操作，例如：
一年有多少週數？
如何自定每週的第一天是星期幾？
指定月份有幾週？
指定月份的第一天是一年之中的第幾週？
指定月份的最後一天是一年之中的第幾週？
指定週數的第一天，其日期為何？
指定週數的最後一天，其日期為何？
上一篇文章「把正在開發的網站專案新增到IIS的站台」有說到如何在IIS去建立一個站台並將目錄並使用網站專案的路徑，然後在文章最後也說到會說明如何不使用「F5」來進行偵錯，時常看到專案的成員在編寫程式到一個段落後，看測試功能時，就會按下「F5」去執行，這時候就會看到Visual Studio 進入偵錯模式，然後開啟瀏覽器，接下來瀏覽器開啟網站的預設起始頁，再來就是開始測試他所編寫的功能，假如他所寫的功能，其路徑是在網站某個深處時，就開始要拔山涉水的一直點連結或是操作某些功能後才能到達，多半都只是為了要去測試那一些功能而已，卻要花那麼多的時間成本，實在是不值得。
而「附加至處理序」則是可以讓你在瀏覽器還在操作專案的某些功能時，如果想要在當前頁面進行偵錯時，就派上用場，不必重新啟動瀏覽器也不必整個程序重來一遍（除了有重新建置過且已有加入身分認證的除外）。
如果再搭配上「把正在開發的網站專案新增到IIS的站台」，既使還沒開啟Visual Studio的狀況下，可以瀏覽網站，要進行偵錯時，再把Visual Studio打開並載入專案後去使用「附加至處理序」來進行偵錯。
很多人在 Visual Studio 開發網站專案時，通常一個功能寫完要執行的時候，都會直接按下「F5」然後進入偵錯模式，然後接著開啟瀏覽器，開始進行功能的測試，但是當我們在瀏覽器的功能測試結束後要繼續編寫程式，就回到 Visual Studio 裡，再停止偵錯模式然後繼續寫程式。而停止偵錯模式後，那個自動開啟的瀏覽器也就跟著自動關閉（如果預設的瀏覽器是IE）。
而 Visual Studio 按下F5後進入偵錯模式，是使用 Visual Studio 內建的 ASP.NET 開發伺服器(ASP.NET Developement Server)，但是有些時候開發環境下的測試就是會與上線到正式環境有所差異，這是因為正式的IIS與 Visual Studio 內建的 ASP.NET 開發伺服器有所不同，在 Visual Studio 的 ASP.NET 開發伺服器會有無法執行的地方，詳細情況可參閱以下文章：
The Will Will Web | ASP.NET 開發人員應使用 IIS Express 進行開發與測試
這篇文章主要是介紹IIS Express，但那必須開發環境是有使用Visual Studio 2010 SP1才可以。
所以接下來就簡單介紹一下如何在IIS中新增一個網站，然後指定到目前開發的網站專案目錄。
之前以兩篇文章介紹了有關MiniProfiler在ASP.NET MVC 2 與 ASP.NET MVC 3 的應用
「ASP.NET MVC 2 + MiniProfiler 偵測執行效能」
「ASP.NET MVC 3 + MiniProfiler.MVC3 偵測執行效能」
今天試著把MiniProfiler給裝在之前的資料分頁的範例專案「ASP.NET MVC - 資料分頁(5) 範例程式下載」，
在我自定的MvcSimplePager以及 MvcSimplePostPager, MvcSimplePostPager + Ajax都沒有什麼問題，
但是在原生的MvcPaging的Pager就出現了錯誤，如下：
所有的分頁連結變成了「http://localhost:4371/mini-profiler-results?page=2」
URL應該是 Home/PageMethod1 的部份都被代換成 mini-profiler-result 了……
上一篇文章「ASP.NET MVC2 + MiniProfiler 偵測執行效能」介紹了在MVC2的專案中使用miniprofiler偵測執行效能，
而文章的最後有說到，MVC2 + miniprofiler並無法去偵測到EF所產生的SQL指令碼，
或許是還要改某些地方才可以讓MVC2專案偵測EF的SQL執行，我就沒有再多去研究，
但是看到許多的文章都是以MVC3來做說明，另外在Nuget上面也有看到miniprofiler.MVC3，
所以就直接用MVC3開個新專案來使用miniprofiler。
有時候常常會遇到執行效能的問題，除了找尋讓執行效能延遲的原因，也希望能夠知道每個步驟與環節所耗費的時間，
這樣就可以知道哪些地方發生了問題，或是使用了錯誤的程式寫法而使得系統效能出現問題，
很多人會用的老方法就是在程式執行的開始與結束去記錄時間，然後再把時間做相減後得到一個執行的時間，
但是這會遇到很多個問題，
第一個會遇到的就是，開發時期可以這麼做，
但如果要部屬到測試機或是正式機前，必須要手忙腳亂的把這些用來偵測的程式給移除或是註解起來，
而且還有可能會有不小心遺漏的地方。
第二個會遇到的問題將事前項問題最後所提到的，如果你要偵測的地方很多，那麼你要去下偵測程式碼的地方也很多。
第三個會遇到的問題是，當你所開發的專案有切分很多層時，往往在畫面上就不容易去顯示除了顯示層以外其他層所要偵測的資料。
如果有一個工具可以解決以上的問題，那麼在系統開發就會很方便也更容易及早發現影響效能的地方。
建立類別的時候，往往會遇到這兩個成員：Property 以及 Field，熟悉物件導向對於物件封裝的人應該是可以區分這兩種成員的差別，但是對於初學者或是對 OO 不熟悉的人是搞不清楚，明明兩種都是可以去儲存以及取得物件中的資料，但是到底兩者有什麼差別呢？又應該在什麼樣的情況下去使用這兩種成員？
所以就看到很多人都是直接在自訂類別中使用 Field，這狀況尤其在 ASP.NET MVC 的 ViewModel 最多，為什麼要捨 Property 而就 Field 呢？因為 Filed 在 Coding 時最快、最方便。反正只要可以存取資料，管他什麼是 Property、Field ……
但是這樣對嗎？
讓我們來認識 Property 與 Field 的差別。
這邊提供這一系列資料分頁(1) ~ (5)的程式範例，
另外這一系列的範例所使用是.Net Framework 4.0，而ASP.NET MVC版本為2，
資料存取層使用的是ADO.NET Entity Framework，
而資料庫所使用的是微軟所提供的Northwind（北風資料庫）
之前幾篇的資料分頁文章裡面所說明的，無論是用HyperLink或是用Post方式，送出後再傳回前端燈一定會Reload，
有的專案會比較要求UI操作，會提出分頁不想要有整頁Reload的情況，而是要用AJAX的方式，只更新分頁資料部分，
在以往採用ASP.NET WebForm開發時，我想大部分的開發者一定會把這種要有AJAX效果的部份給塞到UpdatePanel，
但是在ASP.NET MVC就不需要用這樣的方式來達成AJAX（很多人會覺得不習慣沒有UpdatePanel），
但是ASP.NET MVC+jQuery的搭配下，可以讓我們以更加彈性的方式來完成AJAX分頁的效果。
上一篇資料分頁的文章「ASP.NET MVC - 資料分頁(2) 自訂分頁功能列 MvcSimplePager」最後有說到，
當表單查詢遇到資料分頁時，用原本的資料分頁方式會出現問題，
因為資料分頁於跳頁時是利用HyperLink將頁數資料以Get傳回後端處理，查詢條件就無法一併送到後端去處理，
為了達到這個需求，所以就把原本的MvcSimplePostPager做了一些修改，
讓前端的分頁功能列可以將查詢表單上的條件一起傳回後端，送回前端的資料一樣是維持查詢條件，
所以這篇文章就是說明如何製作一個使用「Post」方式的資料分頁方式。
在「ASP.NET MVC - 資料分頁(1) 使用MvcPaging」這篇文章中已經有介紹如何使用MvcPaging來做資料分頁，
而MvcPaging所提供的Html.Pager()所產生的分頁功能列是比較陽春的，
就是有各個頁數的連結以及上一頁、下一頁的連結，但有時候客戶那邊會希望分頁的功能列可以有些變化，
在不去修改MvcPaging原始碼的情況下，我們可以在IPagedList<T>的基礎上去自己設計一個分頁功能頁。
以下說明如何自訂分頁功能列（姑且命名為：MvcSimplePager）
上一篇文章已經有介紹過「Visual Studio 快速鍵整理 - 編輯」，接下來這一邊就介紹偵錯與建置時常用的快速鍵。
多記一點快速鍵，讓效率更好一點！
使用Visual Studio來設計.NET程式比起其他程式開發環境來說是比較方便，
因為有太多的功能都整合在這個IDE環境下，再加上VS2010開始提供了擴充管理員功能與新加入的NuGet功能，
在功能擴充與套件更新的操作上就更加方便了，
但是……還是會看到很多人在編寫程式碼的時候，還是習慣寫Code寫到一半時要再去花點時間去操作滑鼠，
然後按下滑鼠的左右鍵來完成一些功能的操作，看在我的眼裡，其實有些操作是可以不用去動用到滑鼠的，
畢竟在寫Code正起勁的時候，還要多花時間去操作滑鼠，對於講求效率的程式設計人員來說，
可以用鍵盤快速鍵來完成的操作就不要多花時間操作滑鼠。
以下整理有關「編輯」時，我常常會去使用到的鍵盤快速鍵，多記一點快速鍵，讓效率更好一點！
做專案的時候除了表單常常碰到之外，資料表格的顯示也是常常需要處理的，
而資料表格的顯示也通常會需要做到資料分頁的功能。
製作ASP.NET WebForm的網頁時，使用GridView的話，可以使用內建的分頁功能，
而在.NET 3.5後還有提供一個DataPager的控制項，專門處理資料分頁的功能。
到了使用ASP.NET MVC來做網頁時，因為沒有控制項的提供，所以包括資料表格就必須要自己處理，
當然，資料分頁的功能也需要自己動手做。
目前網路上已經有很多相關資料分頁套件可以使用，但是這邊就從一個最基本的功能來做介紹，
並延伸之後ASP.NET MVC資料分頁相關介紹。
這也是在網路上所看到的一個問題，
“如果我想要抓一段日期,並秀出在此日期區間每個星期二的日期
2011/09/14~2011/10/14 每個星期二 請問要如何抓出”
所然說提問者是用VB語法，但是用C#來寫也是一樣的，主要是邏輯的部份是相同的。
今天在網路上看到有人提出一個問題：
字串一：ABCDEF
字串二：ABC1D2E3F
要用怎麼取出兩個字串差異的 123 呢？
並不是取出數字的部份，這邊只是做個簡單示意，主要是取出兩個字串有差異的部份，一開始覺得這沒有什麼，但是細想一下…這其實也蠻好玩的，就當做練習題來做做看。
在做專案的時候，有可能會去接到不知道多解以前寫的專案，原始碼早就不知道丟到哪去了，
所留下的文件也是零零落落，而且最慘的是當初做專案時根本沒有使用版本控制，
反正就是只有剩下DLL檔案，其他什麼都沒有！
另外還有一種狀況是想要看看某些組件是怎麼做的，但是這些組件並沒有開放原始碼。
在之前都會用「.NET Reflector」這個工具來去查看這些組件的原始檔，
但是現在「.NET Reflector」要開始收費了，而且一套標準版的費用就要美金35元，
而且標準版還是只有一般的執行版本，並沒有提供Visual Studio的整合套件，
如果需要Visual Studio的整合套件的話就要美金65元，而且更高的版本更要美金95元！
又不是三不五時都會需要反組譯去看原始碼，所以這個錢就花不太下。
還好有另外兩個功能相近的反組譯工具，可以取代「.NET Reflector」。
自從.NET Framework 3.0 發佈LINQ（音同 Link）之後，對於程式開發人員於專案中的資料庫操作或是集合物件的操作，都有了很大的變化，不論是使用LINQ to SQL 或是 ADO.NET Entity Framework還是對於集合物件的資料查詢、彙整等操作，都可以使用一致性的查詢方式來操作資料。
然而並不是每個.NET開發人員對於LINQ是那麼的熟悉，我從2007年開始接觸LINQ後，至今已經也差不多快四年了，也還是會在周遭聽到或看到：
如果有個方便的工具可以拿來練習LINQ的話，或許對於LINQ可以認識更多。
如果在專案開發時，不用頻繁的F5執行程式看結果，而是可以在工具裡去下LINQ語法然後立即驗證的話，可以使開發更加的便利。
不用再找了！LINQPad就是這樣的一個好用到爆炸、.NET開發人員必備的好用工具。
連動式下拉選單在網站中也算是相當常見的功能，在ASP.NET WebForm裡，很多開發者都會直接在UpdatePanel中做解決，但是這樣的方式其實對於效能來說並不是很好，而往往很多開發者若是沒有對UpdatePanel做好配置的話，常常會有些開發者整個網頁就只有一個UadetePanel，這樣的Ajax也只能說是做假的，而有的開發者如果細分到每個下拉選單都給一個UpdatePanel，那在開發上也蠻瑣碎的，因為頁面上要做Ajax效果的地方通常也不是只有下拉選單而已。
而在ASP.NET MVC的ViewPage則是比較沒有這種顧慮，因為在MVC是用不到UpdatePanel，充分搭配 jQuery 下，ASP.NET MVC所做的Ajax效果是可以比WebForm來得更為靈活以及輕巧，以下就介紹幾種在ASP.NET MVC下製作連動式下拉選單的方法。
下拉選單在網頁表單上是個使用相當頻繁的物件，以前在還沒有使用 jQuery 時，對於下拉選單的操作就不是那麼的直覺與方便，現在有了 jQuery 之後，操作下拉選單就同如虎添翼一般，但是在專案執行的過程中，還是時常看到令人哭笑不得的操作方式，看久了就想整理一篇文章，記錄一下使用 jQuery 操作下拉選單的各種方法與心得，總之就是要消除不良寫法以及去除沒有效率的操作！
在JavaScript裡，有小數點的數值運算有時會出現讓無言的結果，例如以下：
沒有出現預期的4.31，反而出現了4.3100000000000005……這也差太多了
在C#中對於字串的串接處理或是字串處理時可以使用String.Format這個方法，
處理格式化的字串上會比較清楚，而且減少錯誤，
更重要的是少用 + 的串接方式，可以減少多餘物件的建立，
題外話：
竟然有人跟我說用String.Concat, String.Format方式處理字串連接會比直接用 + 來得慢…
而且還寫個測試給我看，但是他忽略了，多次迴圈處理字串不應當用固定的短字串做測試，
應該用隨機產生長短不一的字串來測試才看得出差異，改天來做個測試！
