上篇 提到使用 Prism 來建立 Mock Server，經同事反饋，他期望能使用類似像 Wiremock 有 API 可以在測試步驟根據場景快速的定義 Mock Server 的回傳值，而我期望除了用 API 動態的決定 Mock Server 的回傳值之外，還能匯入 Open API/Swagger，於是我把我手上收集的 Mock Server 清單玩了一遍，發現這一套 Mock Server 可以滿足我需要的
上篇 有提到可以透過 ASP.NET / ASP.NET Core 的 HttpContext 來傳遞狀態，由於他的生命週期很短，每一個調用者擁有獨立的狀態，很適合用來跨層傳遞狀態；現在，我想要降低對 HttpContext 的依賴，改由自訂的 ContextAccessor 保留物件的狀態，傳遞系統所必要的狀態，統一由一個點進行修改，比如登入帳號、追蹤 Id，其他的點，只能取用不能修改。
一直以來都是用 NSwag 來產生 OpenAPI Client & Server Code，但它所產生出來的 Client Code 會 throw Exception，這讓我在商業流程的控制需要額外付出一些心力，為了解決這問題，我會額外再墊一層，最近逛到有人分享 Refit 這個套件，它所產生出來的具名 Method 不會拋出例外，讓我可以根據 HttpStatusCode + Error Content 控制商業流程。
我曾經在端點使用 Dictionary<string,object> 型別，當調用端傳入 {"name":null} 時，移除 name key；傳入 {"name":"123"} 時，name 得的值等於 "123"，這樣便能夠做到類似 Json Path 的功能，參考上篇，在不改變合約的情況之下，這次我想要改用 Morcatko.AspNetCore.JsonMergePatch 來實現更新部分資源並且讓端點的合約變成強型別。
ASP.NET Core 提供了健康檢查的 Middleware，可以讓我們很輕鬆的知道應用程式目前的本身的狀態以及應用程式所依賴其他服務的狀態；也可以讓容器協調器進行重新啟動容器或是暫停服務，比如 K8s 的 Liveness、Readiness
令人驚喜的是 AspNetCore.HealthChecks.UI 提供 UI / Alert 讓監視系統變得更有效率了
在介接其他人寫的 Web API 時，可以透過 Mock Server 來模擬對方會回傳的資料，比如說 json-server，但這樣往往會因為兩造之間沒有一個合約、規範，各自實作，導致最後在整合的時落差太大；理論上，雙方基於合約、規範，進行開發，最後在整合的時候應該有問題的狀況應該會小一點，Prism 是套基於 Swagger/OpenAPI Specification 的 Mock Server，在 OpenAPI 的生態系裡面算是蠻完整的解決方案之一，接下來，是我對它在使用上的小小心得。
當我們的 Swagger / OpenAPI Specification 寫到某一個程度就會開始想要模組化、重用它，例如，當 components/schemas 節點需要被其他的檔案參照。
以往，在 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 提供了許多身分驗證的 Middleware，內建的 AuthenticationMiddleware (app.UseAuthentication) 需要搭配 AuthenticationHandler，這裡我將介紹如何使用自訂的身分驗證跟 AuthenticationMiddleware 的串接，驗證成功後替使用者建立身分識別
本以為 Jetbrains Rider 連結 Sql Server Localdb 很簡單，沒想到還是踩了個小坑，簡單紀錄一下。