以往我都是透過 ValidationContext 來進行模型驗證，在 ASP.NET 的模型綁定，骨子裡面也是使用 ValidationContext，他必須要依賴 Validate Attribute，這次我的需求是要驗證 Dictionary<string, object>，ValidationContext 可能就沒有那麼適合，FluentValidation 是 .NET 生態裡的驗證框架， 這次我打算採用它來實作 Dictionary<string,object> 的驗證。
我使用預設的 System.Text.Json 反序列化時 JsonSerializer.Deserialize<Dictionary<string, object>>(json)，得到 JsonElement，再透過 JsonElement.Get 系列的方法才能取得正確的資料，這樣有點繁瑣，為此我找到了解方，自行實作 JsonConverter，緊接著，來看看我怎麼處理的
一旦 Web API 部署並開始使用後，它應該是可靠的，並且不應該因任何原因而中斷。另一方面，隨著需求的變化，我們需要更新 Web API 代碼，但這應該不破壞目前 API 的情況下完成，因此新舊版本的 Web API 都將處於活動狀態，功能也要正常。這時候就要靠 Web API 版本控制，我們靠它用於處理不同版本的Web API。微軟的 Microsoft.AspNetCore.Mvc.Versioning 可以讓我們輕易的完成此項目，但我在整合到 Swagger UI / Swashbuckle.AspNetCore 的時候碰到了一些關卡，所幸順利的解決了，以下是我的實作筆記。
前幾年編寫了 [Swagger] 一些 Swagger 編寫文件的技巧和 Client Code Gen ，不過，已經不適用 ASP.NET Core 6，正好，團隊正在重視 API 文件，正好趁這機會更新 Swashbuckle.AspNetCore 使用
前面幾篇使用 ChangeTracking 來幫我們追蹤物件狀態，但他必須公開狀態讓外部可以修改，為了解決不被外部隨意修改的問題，可以利用深複製回傳一份不同實例的物件，這樣就可以不被外部影響；操作資料庫仍是使用 EF / EF Core，當然這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
上一篇提到了 ChangeTracking + EFCore.BulkExtensions.BatchUpdate，可以很輕易的幫我們產生出有異動的 Update SQL 語法，如何使用 ChangeTracking 追蹤物件變化再透過 EFCore.BulkExtensions 存到資料庫
很可惜的是 EFCore.BulkExtensions.BatchUpdate 沒有支援異動多張資料表，對於資料庫命令的往返會隨著異動的資料表而增加，這次我想要改使用 EF Core 原生的異動追蹤。
追蹤異動變化使用 ChangeTracking ，消化異動並存放到操作資料庫則使用 EF / EF Core，當然，這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
當我們需要異動資料庫某一筆資料的某些欄位，可以通過追蹤機制來記錄那些欄位被改變了，除了自己開發之外，還可以考慮 ChangeTracking，它是一套可以輕易的幫我們追蹤物件、集合的利器，不過，有一點可惜的是他最後一次更新是在 2019
接下來，我想要利用這個追蹤機制幫我完成資料表的部分更新，有異動的欄位才更新。
追蹤異動變化使用 ChangeTracking ，消化異動並存放到操作資料庫則使用 EF / EF Core，當然，這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
使用 .env (環境變數) 配置系統，是我們常用的手段之一，他的格式非常的簡單，就 key = value，攤平的結構
讀取 .env 檔也不是甚麼太大的問題，所以我打算將他整合到 IConfiguration
以往我都使用 dotTrace 診斷 .NET 應用程式的使用狀況，可以得知執行時間、佔用記憶體、SQL Command 等。
但，NET Core 沒有支援 SQL ETW，代表攔截不到有關 SQL 的命令，於是我得尋求其它解方，MiniProfiler 則是這次的調查對象。
以往，大量資料異動我們都知道要使用 Bulk 系列的 API，EFCore.BulkExtensions 除了提供大量資料異動之外，還有查詢後異動、BulkRead(Where In)，這裡我將先記錄初步的使用方式，後續有其他心得再補上