上一篇文章說明了使用 EF6 的 Intercepting 與 NLog 來紀錄觀察分頁的執行內容與效能，在文末也提到 MiniProfiler 與 Clutch.Diagnostics.EntityFramework 目前尚未支援 EF6，如果不想使用 EF6 Intercepting 的話，其實還可以使用 Glimpse.EF 來觀察，Glimpse 在兩年多前也曾經寫文章介紹過，但可能當時界面與功能還蠻陽春，所以注意的人不是很多（文章的瀏覽數量都少少的），不過在去年開始進行了界面的改版而且版本更新進度也變得頻繁（因為 redgate 投入支援），另外也因為有提供介面讓開發者可以開發其他功能，所以有許多相當實用的功能可以使用，而且不限定 ASP.NET MVC 才能使用，提供 ASP.NET WebForm 的功能也相當豐富與使用，有興趣的朋友可以玩玩看。
這一篇就來介紹怎麼使用 Glimpse 與 Glimpse.EF 來觀察分頁的執行。
這陣子有網友詢問為何使用 PagedList.Mvc 所執行的效能為何會相當緩慢，而在看過程式碼後並未發現到有做任何特殊的處理或複雜的操作，就只是從 DbContext 將資料取出後再使用 ToPagedList() 方法取得分頁資料，另外我也曾建議他可以使用 LINQPad 去做單純的 EF 取得資料的觀察，這麼做是要將資料存取的環境給單純化，排除 ASP.NET MVC 環境的影響，而這位朋友回報說在 LINQPad 執行 EF 的取得資料處理是很快的，因為這位網友只給我看 Controller 裡 Action 方法的程式內容而已，我無從了解前端 View 是否有做其他的處理，所以我也不知道造成執行效能緩慢的原因為何。
無論使用 MvcPaging 或是 PagedList.Mvc，在取得分頁資料的操作處理上我並沒有遇到這樣的狀況，這些分頁套件並不是造成效能緩慢的主因，因為在我所處理過上萬筆甚至上百萬筆資料的分頁操作都不曾發生這樣的事情，其實造成效能緩慢的原因有很多可能，所以就必須一個一個去找尋原因，例如說將 PagedList.Mvc 從網站裡移除，然後觀察一次取得所有資料是否緩慢、使用 Skip Take 方法取得部份資料是否緩慢、不使用 EF 而直接使用 ADO.NET 執行 SQL Command、調整資料庫的設計或加上索引等，藉由這些的方式將原因給找出，而不是直接懷疑或認定 PagedList.Mvc 就是兇手。
這一篇簡單說明在 ASP.NET MVC 5 使用 EF 6 的 Intercepting 功能來觀察 PagedList.Mvc 的處理與執行的時間。
這個題目其實蠻簡單的，有時後會需要將接收到的 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，其實也很簡單，相信很多人看過之前文章的參考連結就應該知道要怎麼使用，不過這邊還是稍做說明。
