余小章 @ 大內殿堂

上篇 有提到可以透過 ASP.NET / ASP.NET Core 的 HttpContext 來傳遞狀態，由於他的生命週期很短，每一個調用者擁有獨立的狀態，很適合用來跨層傳遞狀態；現在，我想要降低對 HttpContext 的依賴，改由自訂的 ContextAccessor 保留物件的狀態，傳遞系統所必要的狀態，統一由一個點進行修改，比如登入帳號、追蹤 Id，其他的點，只能取用不能修改。

當我們想要讓物件延遲實例化時，可以透過 Lazy<T> + Delegate 來實現這件事，同樣的在 DI Container 也可以套件，無意間發現 Lazy Proxy 這個套件，可以簡化配置 Lazy 的配置，立馬收入武器內

MongoDB 近幾年來發展的很穩定，也是我心目中 NoSQL 選擇方案之一，對於 .NET 的開發者而言，開發體驗也算是不錯，在這裡我會簡單的分享怎麼建立  .NET + MongoDB 開發環境以及簡單的 CRUD 操作

Exception 是微軟預設中斷流程的手段，要控制好流程就要好好的處理例外，也就是寫 try catch，這會讓流程控制的程式碼看起來很凌亂。於是我需要幾個原則

1. 被流程所呼叫的方法都要處理好 Exception/錯誤(根據需求場景，例如：找不到某個資料) 並回傳 Failure 物件
2. 若有攔截到 Exception，Failure 物件要裝載 Exception 訊息，並且給予該例外正確的錯誤訊息。
3. 盡量在最外層紀錄 Failure 日誌，例如，Controller、Application Layer
4. Web API 回傳值不可以包含 Exception

以上是我的原則，在你的團隊裡面應該也有自己的錯誤處理機制；接下來，我用 ASP.NET Core Web API 實際的演練一遍

微軟一直以來都有提供 Model Validation 讓我們更容易的進行前置條件檢查，這次我想要在 ASP.NET Core Web API 回傳一致性的錯誤結構，捨棄預設錯誤的結構，接下來我將演練 Model Validation 以及 FluentValidation  的使用方式。 

我曾經在端點使用 Dictionary<string,object> 型別，當調用端傳入 {"name":null} 時，移除 name key；傳入 {"name":"123"} 時，name 得的值等於 "123"，這樣便能夠做到類似 Json Path 的功能，參考上篇，在不改變合約的情況之下，這次我想要改用 Morcatko.AspNetCore.JsonMergePatch 來實現更新部分資源並且讓端點的合約變成強型別。

在軟體生命週期地演進的過程中，在不同的階段可能需要將某一些功能啟用或停用，這時候就可以選擇 Feature Toggle，微軟的 Microsoft.FeatureManagement 正好是選擇之一，除了基本的 Feature Toggle Flags 之外，也整合到 ASP.NET Core 的生命週期裡面，還有整合 Azure。下圖出自 針對目標受眾啟用分段推出功能 - Azure App Configuration | Microsoft Learn

Redis 已經幾乎是系統必備的基礎建設，在本機搭建一套 Local Server，除了用於開發除錯之外，它也可以用來當成測試替身(模擬器)，接下來，就來分享我的配置

上一篇，我們學習了怎麼自訂身分驗證
ASP.NET Core 6 實作自訂 Authentication 身份驗證，以 Basic Authentication 例 | 余小章 @ 大內殿堂 - 點部落 (dotblogs.com.tw) ，如果一個服務需要有多種以上的驗證，ASP.NET Core 也有支援，接下來我們就來看看怎麼在服務裡面增加多種驗證吧

ASP.NET Core 提供了健康檢查的 Middleware，可以讓我們很輕鬆的知道應用程式目前的本身的狀態以及應用程式所依賴其他服務的狀態；也可以讓容器協調器進行重新啟動容器或是暫停服務，比如 K8s 的 Liveness、Readiness

令人驚喜的是 AspNetCore.HealthChecks.UI 提供 UI / Alert 讓監視系統變得更有效率了