這個題目其實蠻簡單的，有時後會需要將接收到的 QueryString 再加以處理，因為 QueryString 是屬於 NameValue 的結構，如下：
ID=12345678&FirstName=OOO&LastName=xxx如果 QueryString 的內容不是又臭又長的時候，可以直接使用 HttpUtility.ParseQueryString() 方法將 QueryString 轉換為 NameValueCollection，然後可以依據 Name 來取得 Value 的內容。
但需要將 QueryString 轉成指定型別的物件呢？好像沒有內建的方法是可以直接將 NameValueCollection 轉成物件，不過還是有方法可以做這樣的處理，只是需要多做幾次簡單的轉換處理而已。
前面一系列都在介紹 Attribute Routing 的內容，相較於在 RouteConfig.cs 裡設定 Route，使用 Attribute Routing 是比較彈性與方便，但是在管理上就不是那麼容易了，因為散在各處的 Controller 都有可能使用到 Attribute Routing 來做 Route 設定，以前只要在 RouteConfig.cs 與 Areas 裡的 AreaRegistration 就可以看到所有的 Route，現在則是每個 Controller 都要打開來看才行。
不過在 Visual Studio 裡有個工具則是一次列出專案裡的所有 Route 設定，讓我們可以馬上一目了然，並且還有提供檢測 Route Mapping 功能，讓我們未執行網站前就可以知道設定的 Route 是否能夠正確的 Mapping。
這次要說明的是 Areas 裡使用 Attribute Routing，其實也很簡單，相信很多人看過之前文章的參考連結就應該知道要怎麼使用，不過這邊還是稍做說明。
上一篇「ASP.NET MVC - 使用 Attribute Routing」介紹了基本的使用以及稍做變化的設定方式，這一篇再來簡短的說明路徑設定以及在 Areas 下使用 RouteArea 的方式。
Attribute Routing 在原作者 Tim McCall 捐獻給 .NET Framework 後，在 ASP.NET MVC 5 與 ASP.NET Web API 2 的專案裡就可以使用，如果是使用 ASP.NET MVC 5 專案的話，可以在 SystemWeb.Mvc 命名空間裡看到，
這一篇將會對於 Attribute Routing 的使用做個簡單的說明。
是的，這是一篇吹毛求疵的文章，並不是要告訴各位如何建立客製的 Action Filters，而是跟各位說「應該怎麼建立」Action Filters。
也許有人看完會覺得根本沒有什麼重點，但是必須要跟各位強調的就是「魔鬼藏在細節裡」，專案開發時對於細節多多的注意，並且要堅持與習慣一些作法，無論是自己一個人開發或是多人開發，只要共同依循、遵守一些默契與規定，在管理與開發維護上都會有很大的幫助與提昇開發上的效率。
之前的文章「ASP.NET MVC 實做具有多個角色權限的登入功能」裡我們做出了一個登出入的功能，使用者登入成功之後將使用者的多個角色資料給放置到 FormAuthentication 的 UserData 裡，當有需要驗證使用者時，在 HttpApplication.AuthenticateRequest 事件裡取得使用者的識別 ( Identity ) 並且建立 IPrincipal 物件然後放到 HttpContext.Current.User 中，其中的 IPricipal 物件包含 FormsIdentity 以及使用者角色資料。
之前的例子是我們在處理使用者的登入時，當使用者登入成功後會建立 FormsAuthenticationTicket 物件，然後於加密後存入 Cookie 之中，而我們是把 FormsAuthenticationTicket 的 Name 用來放使用者的 ID，而 UserData 則是用來放 Roles（角色資料）。
其實我們可以改用其他的做法，這邊將會介紹我們可以繼承 RoleProvider 以建立自己的 RoleProvider，讓 FormsAuthenticationTicket 的 Name 與 UserData 分別存放使用者顯示名稱與使用者資料 ID。
其實這邊的內容是擷取「給 ASP.NET MVC 初學者 - 兩種主要 View Engine 的對照」的內容再加以補充，因為看到有太多人在 View 的檔案名稱管理上都是相當隨便，這樣在專案開發時（尤其是大型專案與多人開發的時候）將會發生管理上以及編輯效率上的問題，所以一定要正視這個原則。
如果這一點都無法作到的話，別跟我說你是在開發 ASP.NET MVC 專案，因為連這一點基本的原則都沒有堅持住的話，那麼在 View 裡面寫大量的伺服端程式或是直接讀取資料庫來做處理的各種很扯的荒唐行徑都會做得出來。
在上個月（2013-11）針對 Visual Studio 2012 有發佈了一項新的更新「ASP.NET and Web Tools 2013.1 for Visual Studio 2012」，而這一項的功能更新是對應 VS2013 的功能，也就是說 VS2013 可以進行開發的項目也可以在 VS2012 上面進行開發（不過還是會略有不同），有關此一功能更新項目的內容，可以參考下面的說明，
Release Notes for ASP.NET and Web Tools 2013.1 for Visual Studio 2012 : The Official Microsoft ASP.NET Site
http://www.asp.net/visual-studio/overview/2012/aspnet-and-web-tools-20131-for-visual-studio-2012
本篇會針對 VS2012 開發 ASP.NET MVC 5 的部份做簡短的介紹。
上一篇「ASP.NET MVC 使用政府公開資料 Part.2 - 增加條件過濾」已經完成了條件過濾的功能，但是一堆資料全部攤在眼前，我想不是每個人都能全部看完，所以在瀏覽資料時如果有分頁功能還是會比較好一些，而這一次所加入的分頁功能是使用之前有介紹過得 PagedList，但不會使用一般我們常用的 ToPagedList 而是使用 StaticPagedList。
對於 PagedList 這個套件不熟悉的朋友，可以先看之前的文章：
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc：分頁列樣式
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc：自訂分頁資訊顯示
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc：AJAX
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc：Table 的 Checkbox
在「ASP.NET MVC 使用政府公開資料 Part.1」這一篇文章裡我們使用 ASP.NET MVC 透過 HttpClient 取得新北市政府公開資料的「WiFi 熱點」資料，最後將取得的資料存放於 SystemRuntime.Cache 類別的快取當中，這一系列的操作都是使用 Async/Await 非同步的方式來做處理。
因為我們所取得的是原始的資料，上千筆的資料一次全部顯示還真的看不太清楚，所以我們可以就所取得的資料來進行篩選，在頁面上增加條件過濾的選項，讓使用者可以藉由條件過濾來取得更精確的內容。
對於最近遇到的情況做了一些觀察與思考，因為之前沒有這麼作過與想過，所以看到有人這麼做的時候，當下的衝擊與震驚是相當大，然後周遭的人都被我這問題搞得有點煩，所以這幾天一直反覆思考著，因為對於比較深入的內容無法做仔細的研究與探討，所以只有將看到的相關內容與觀察的結果以文字方式做個紀錄。
