這算是個練習的題目,原本覺得應該是個簡單的應用,沒想到實做下去遇到了幾個進階的操作,還蠻有趣的,用的是 ASP.NET Core WebAPI,但如果要用在 ASP.NET WebAPI 專案裡也是可以的,程式的部分並不會有多大的差異。寫程式的過程中還發想出不少的延伸應用情境,所以之後會有幾篇文章跟這篇的內容有所關連。
這篇文章會提到的內容:GZipStream, JsonConvert, AutoMapper
這算是個練習的題目,原本覺得應該是個簡單的應用,沒想到實做下去遇到了幾個進階的操作,還蠻有趣的,用的是 ASP.NET Core WebAPI,但如果要用在 ASP.NET WebAPI 專案裡也是可以的,程式的部分並不會有多大的差異。寫程式的過程中還發想出不少的延伸應用情境,所以之後會有幾篇文章跟這篇的內容有所關連。
這篇文章會提到的內容:GZipStream, JsonConvert, AutoMapper
上一篇「NanoProfiler 對於資料庫存取的監控 - ADO.NET」的最後有講到使用 ADO.NET 進行資料存取處理雖然可以使用 NanoProfiler 將程式的執行效能作監控,但是卻無法將執行的 T-SQL 內容給記錄起來,所以算是一個未完成品。
現在這一篇則是改用 Dapper 取代 ADO.NET 的操作,然後再使用 NanoProfiler.Data 去進行資料存取的監控並且將執行的 T-SQL 給記錄起來。
前一篇「使用 NanoProfiler 對 ASP.NET Web API 進行性能監控」介紹了 NanoPrifiler 這個套件,讓我們可以在 ASP.NET MVC / WebAPI 或 WCF 等專案裡去監控程式執行的效能,因為是第一篇,所以只有簡單的說明怎麼在 Controller 類別的 Action 方法裡的使用方式,所以在 NanoProfiler 的 Profilering Result 頁面裡只有呈現 Controller 的 Action 裡被 ProfilingSession 給包起來的程式執行數據。
很多人誤會說只要在某個地方用程式給包起來之後就會將有用到的所有程式效能數據都能夠抓出來,這…… 真的有點誤會了,其實 NanoProfiler 並沒有如此厲害,要是真的那麼厲害的話,這樣的程式也太恐怖了些,其實效能數據的監控並不是全部程式的執行效能數據都抓出來就可以讓我們了解程式的狀況,因為太多的數據呈現反而會失去焦點與意義,而是應該對於執行效能有疑慮或是要詳加注意的部分再去做監控就可以。所以 NanoProfiler 的效能監控是由我們來決定那些程式需要被監控,有需要監控的地方再去把程式給包起來就好。
這一篇來說明對於使用 ADO.NET 進行資料庫存取的 Repository 要如何使用 NanoProfiler.Data 去做到監控與執行 T-SQL 的記錄呈現。
在開發 ASP.NET MVC 網站的時候,我會使用 MiniProfiler 或 Glimpse 來監控每一個頁裡各種功能的執行性能,這在之前有寫了多篇文章作介紹,然後也在 twMVC#15 以「開發的效能與效率」這個 Session 裡也做了介紹和說明。但是到了開發 ASP.NET Web API 服務的時候,因為沒有頁面,所以也就無法使用 MiniProfiler 或 Glimpse 等工具去對每次的 API 執行去做監控,以致於就會相當仰賴 Log 記錄,在想要監控的程式片段去計算執行時間與寫入 Log,但是這樣的方式相當沒有效率,而且事後去查看 Log 也要當浪費很多時間才能把相關數據給整理出來。
在 2014 年底,我在 Nuget 的 Release 訊息裡發現了一個名為「NanoPrifiler」的套件,當時的介紹文章相當少,大概只有作者部落格裡的兩篇文章(第三篇文章還是到了 2015 年八月才發佈),而且我在 2014 年看到的時候還沒有放在 Github 分享出來(原本一開始有放在 Github 上,但是後來又關閉,現在已經重新公開),一開始我是被他的介紹與文章說明給吸引,直覺這個套件就是我所想要的,所以花了一點時間去研究,接著在 2015 年初就全面導入到專案開發裡,甚至於之後公司裡幾個後續所開發的 ASP.NET Web API 專案也都導入使用 NanoProfiler。
在 2015 年 12 月裡所舉行的 twMVC#21,我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家,而到了現在才有時間將使用、安裝的說明給整理出來,所以將會有一系列的文章說明如何使用 NanoProfiler。
前不久在 feedly 裡看到訂閱的 Mikesdotnetting 部落格介紹了一個免費的 ASP.NET 監控工具「Prefix」,大致看了一下介紹,發現到這的確是個不錯的工具,所以就寫篇文章來做個簡單介紹。
這部落格也介紹了一些 Profile 的工具,例如 miniProfiler, Glimpse 等,但這個 Prefix 與前面所提的有什麼不同呢?看下去就知道。
經過兩篇文章的鋪陳,總算來到了最後一篇,將會把修改過的最後完成版提供給各位,讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。
ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
接續上一篇的內容,來看看最原始的做法有些什麼樣的問題,先開門見山做個說明,這一篇會再沿用別人所提供的改良做法,不過最後的結果依舊還是會有一些問題存在,所以最後在第三篇的文章裡將會提供我所修改過的程式碼,而這也是我開發的專案以及部門其他開發團隊所使用的方法。
之前介紹了幾篇在開發 ASP.NET Web API 專案時會使用到的功能:
ASP.NET Web Api - Help Page
ASP.NET Web API 文件產生器 - 使用 Swagger
Swashbuckle - Swagger for Web Api 顯示內容的調整
雖然 Help Page 可以提供專案 API 功能說明文件的查看,而 Swagger 除了涵蓋 Help Page 所提供的文件查看功能外,也可以直接在頁面上操作 API 並且立即得到執行結果。
在開發過程中,開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等,如果開發人員只有一個人的時候,在 Postman 裡增加或管理 Collection, API 都還算是可以控制,但如果是多人開發團隊共同開發一個 Web API 專案時,就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異,所以就必須要有一個能夠一致化 API Collection 的功能,讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。
前一篇簡單介紹如何在一個 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 功能。
這個功能的主題其實有很多人都寫過了,不過為了之後的文章,所以還是要先寫出這一篇。
大家也都知道 ASP.NET Web Api 2 都已經有內建了 Help Page 的功能,這是一個可以產生對應 API 服務的線上文件產生器,所謂的產生並不是可以幫我們做出一份 Word 或是 PDF 檔,而是指將我們所開發的 API 服務相關的輸入、輸出、Resource 等資料經由 Help Page 的功能處理並建立好網頁,在網頁上去提供了這些 API 服務的相關資訊,以方便介接 API 服務的開發人員查看。
這一篇就來簡單地介紹如何在 ASP.NET Web Api 應用服務裡啟用這一個功能。
因為這一年來主要都是在開發 ASP.NET Web Api 專案,Client 端的開發測試工具是使用「Postman」,而我也並非第一次在專案開發裡使用,在這幾年的開發裡都有使用到,只不過這次的角色從介接使用別人所開發的 Web Api 變成開發別人要使用的 Web Api,其實不管哪一種角色,使用這類的工具如何可以更加地瞭解如何應用,那麼就會省下很多很多的時間,而這一篇所要講的就是 Postman 所提供的一個功能「Generate Code Snippet」。
West Wind Web Surge (以下簡稱 WebSurge) 不只是用於 ASP.NET Web API 的壓力測試功能,也可以對 ASP.NET MVC, ASP.NET WebForm 或是其他網站應用服務進行簡單的壓力測試,而 Load Testing 也僅是 WebSurge 其中的一個功能,WebSurge 也有類似 Telerik Fiddler 的功能,可以針對指定的瀏覽器所發出的 Request 和接收的 Response 進行擷取,有興趣的朋友可以去 WebSurge 的官方網站裡進行瞭解。
不過這一篇文章只針對 Load Testing 這個功能作簡單的說明。