這一篇文章的內容是依據我在公司裡所分享的主題「ASP.NET.MVC / Web API 另一種存取方式」再加以整理。接觸 Dapper 這個資料存取套件是有一段時間，但一直都沒有機會使用上，因為之後所做的專案多半都是使用 Entity Framework，而在去年要開始做新專案的時候，因為系統環境以及舊有包袱的緣故，於是我就想起了 Dapper，也的確解決了許多原有的問題並且大來很大的效益。
這一篇介紹 Dapper 並不會有特別深入的使用介紹，大概只能算是入門介紹，最主要的目的是要讓大家能夠知道在現有環境無法使用 ORM 的情況，尤其又是開發 ASP.NET MVC / Web API 的專案，除了 Entity Framework 之外能夠有其他的替代方案。
注意，並不是說 ASP.NET MVC / Web API 才能夠使用 Dapper，任何你之前使用 ADO.NET + T-SQL 所開發的專案都可以使用（一定要先這麼說，不然一定很多人會有所誤解，這是寫部落格文章四年多來，接到無數回應、詢問所得到的心得。）
在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。
Elmah 有提供一個基本的記錄顯示介面，可以讓我們看到有哪些 Exception 被記錄下來，但長久下來要在一大多的 Exception Record 裡去找出問題或是作分析就會是一大難題，因為這個基本的顯示介面是相當陽春的，如果有將這些記錄存在 SQL Server 裡的話，還可以在 SSMS 裡去下 T-SQL 做資料查詢，但是要要查個 Exception 紀錄還要開啟 SSMS 也是蠻累人的，尤其是有些團隊的環境裡是不允許開發人員直接連接正式環境的 SQL Server，所以就無法使用 SSMS 去做查詢了。
如果有將 Elmah 所攔截的例外錯誤給存放到「SQL Server」的團隊，這邊向你們介紹一個簡單方便的套件「ASP.NET MVC ELMAH Dashboard」
2009 年在台灣微軟 7F 的一場由 Will 保哥所帶來的一個多小時教學課程開始，我第一次接觸了 ASP.NET MVC，當時的我對於這項技術還是懵懵懂懂，整場下來猶如走馬看花一般，太多觀念與實作方式與當時我所熟悉的 ASP.NET WebForm 有著極大的不同，但當時對我而言，比較讓我不明白的是在 View, Controller 以及 Route，因為這是 WebForm 所沒有的，但已經使用 LINQ to SQL 與 Entity Framework, 物件導向程式開發的我來說，在 Model 部分是沒有讓我有任何的不明白，當時我已經不再使用 DataSet, DataTable, DataSource Controls，而在一年之後的七月，我就全面開始以 ASP.NET MVC 在工作上進行專案開發，而從 ASP.NET WebForm 到全面轉換為 ASP.NET MVC 開發，這過程我花了一個多月，不算順利、遇到很多問題、撞了很多牆、衝擊很多觀念，最後就一直到了現在。
這邊分享一些我的看法與建議。
經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。
ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。
在開發過程中，開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等，如果開發人員只有一個人的時候，在 Postman 裡增加或管理 Collection, API 都還算是可以控制，但如果是多人開發團隊共同開發一個 Web API 專案時，就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異，所以就必須要有一個能夠一致化 API Collection 的功能，讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。
關於 Visual Studio 佈景主題的相關文章寫了不少篇，不過都是以 Visual Studio 2013 為主，但是到了 Visual Studio 2015 卻有點不同了，例如 Studio Styles 這個提供了很多編輯器樣式的網站，絕大部分的 Style Setting 雖然依然可以在 VS2015 裡面使用，但因為 VS2015 修改了很多樣式設定的名稱，所以就會有很多地方是相當怪異，最後我就只好使用 VS2015 所提供的預設 Dark 主題，這個主題的編輯器顏色配置算是相當舒服，與 VS2013 or VS2012 原本的 Dark 主題可以感受到明顯的差別，但是看久了之後還是很不習慣，所以血液裡的搞怪因子又讓我起了動手腳的念頭，於是參考了網路上的幾篇文章與說明做了修改，最後的結果還不錯，這篇文章就為各位說明如何去動手腳。
前一篇簡單介紹如何在一個 ASP.NET Web Api 專案裡安裝 Swashbuckle - Swagger for Web Api 這個套件，基本上都沒有什麼難度，特別要注意的就是 Controller 與 Action 方法與相關類別的 XML 文件註解要記得寫以及維護，在一般的使用情況下的 Api 服務資訊提供已經相當清楚了。
不過提供更加清楚的資訊給使用 Api 服務的開發者對於產品的開發與溝通是有絕對幫助的，但老實說，要把 Swagger 寫得好又要能夠搭配 Web Api 後端程式讓資訊可以自動產生，其實也不是容易的事情，這邊就來說明幾個調整顯示資訊的做法。
Swagger 是一套 API 互動文件產生器，使用 HTML 與 Javascript 所編寫的，與之前所介紹的 ASP.NET Web API Help Page 不同的是，Swagger 是一套 Open Source Software，支援了現在許多的 REST API，之所以會說這是一個互動的文件，除了顯示 API 輸出入規格外，也能夠讓使用者即時的在 Swagger UI 介面上進行操作，立刻就能看到執行結果。
這一篇將會簡單說明如何在一個 ASP.NET Web API 專案裡加入 Swagger 功能。