如何使用 Swagger / OpenAPI Specification 先行的開發流程

以往,在 ASP.NET Fx / ASP.NET Core 我會先寫好 Controller(Server Code) 再搭配 NSwag、Swashbuckle.AspCore 產生 Swagger / OpenAPI Specification Doc,一旦要修改它(Spec.)就必須要重新編譯專案,只是要改文件的錯字,也沒有動到 Server Code 的邏輯,卻要重新 Build Server,幾次下來發現這樣似乎不是很聰明。也常常發生過於關注 Server Code 忽略 Specification ,導致兩邊跟不一致。

現在,我先寫 Specification,然後再透過它產生 Controller (Server Code) 讓 Specification 不再強制依賴 Server Code,解除強依賴關係,編寫規範時再也不需要重新建置專案,目前運作起來挺順暢的,接下來,我分享我是怎麼做的

...繼續閱讀 »

ASP.NET Core 6 Middleware 的單元測試

在 ASP.NET Core 的整合測試我們可以使用 WebApplicationFactory、TestServer,這我前面幾篇已經提過了需要的可以參考之前的文章 WebApplicationFactoryTestServer。Middleware 用上述的步驟肯定是沒有問題的,但是需要的環境、步驟也比較多,可能還會因為其他 Middleware 順序所帶來的影響,今天我還要分享 ASP.NET Core內建 Mock HttpContext 做法,讓我們可以快速的針對某一個 Middleware 進行單元測試

...繼續閱讀 »

[ASP.NET Core 6] 讓你的 ASP.NET Core Web API + Swashbuckle.AspNetCore 支援多個版本

一旦 Web API 部署並開始使用後,它應該是可靠的,並且不應該因任何原因而中斷。另一方面,隨著需求的變化,我們需要更新 Web API 代碼,但這應該不破壞目前 API 的情況下完成,因此新舊版本的 Web  API 都將處於活動狀態,功能也要正常。這時候就要靠 Web  API 版本控制,我們靠它用於處理不同版本的Web  API。微軟的   Microsoft.AspNetCore.Mvc.Versioning 可以讓我們輕易的完成此項目,但我在整合到 Swagger UI / Swashbuckle.AspNetCore 的時候碰到了一些關卡,所幸順利的解決了,以下是我的實作筆記。

 

...繼續閱讀 »

自訂追蹤物件變化再透過 EF Core 存到資料庫

前面幾篇使用 ChangeTracking 來幫我們追蹤物件狀態,但他必須公開狀態讓外部可以修改,為了解決不被外部隨意修改的問題,可以利用深複製回傳一份不同實例的物件,這樣就可以不被外部影響;操作資料庫仍是使用 EF / EF Core,當然這不受限,你可以挑選妳喜歡的控制方式,接著,來看看怎麼實現它吧。

...繼續閱讀 »