由 上篇 得知 .NET Core 應用程式可以接收 SIGINT/SIGTERM訊號，來完成 graceful shutdown；在處理批次流程中，當應用程式接收到 SIGINT/SIGTERM 訊號後，就要進入狀態的保存，避免服務被強制中斷，導致狀態混亂。預設 Container 預設等待 10 sec，也就是這個時間範圍內就要完成狀態保存，如果超過時間就可以考慮送出 Timeout 參數，延長工作關閉流程。Linux 執行應用程式的時候有區分 shell model 以及 exec mode，若使用不當，會導致接收不到 SIGINT/SIGTERM 訊號，無法 graceful shutdown。
公司的資料庫有很多功能用到了分表分庫，根據條件，決定要連哪一台資料庫，用哪一張資料表，概念上很簡單，花了一點時間研究，EF Core 的寫法。
我們都知道，可以透過分頁技巧，將大量資料切成小部分回傳給調用端，常見的技巧就是 Offset-based 以及 Cursor-based，我將使用 EF Core + Postgresql 實作分頁
下圖出自：A deep dive into cursor-based pagination in MongoDB (engage.so)
一直以來都是用 NSwag 來產生 OpenAPI Client & Server Code，但它所產生出來的 Client Code 會 throw Exception，這讓我在商業流程的控制需要額外付出一些心力，為了解決這問題，我會額外再墊一層，最近逛到有人分享 Refit 這個套件，它所產生出來的具名 Method 不會拋出例外，讓我可以根據 HttpStatusCode + Error Content 控制商業流程。
上一篇提到了 ChangeTracking + EFCore.BulkExtensions.BatchUpdate，可以很輕易的幫我們產生出有異動的 Update SQL 語法，如何使用 ChangeTracking 追蹤物件變化再透過 EFCore.BulkExtensions 存到資料庫
很可惜的是 EFCore.BulkExtensions.BatchUpdate 沒有支援異動多張資料表，對於資料庫命令的往返會隨著異動的資料表而增加，這次我想要改使用 EF Core 原生的異動追蹤。
追蹤異動變化使用 ChangeTracking ，消化異動並存放到操作資料庫則使用 EF / EF Core，當然，這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
當我們需要異動資料庫某一筆資料的某些欄位，可以通過追蹤機制來記錄那些欄位被改變了，除了自己開發之外，還可以考慮 ChangeTracking，它是一套可以輕易的幫我們追蹤物件、集合的利器，不過，有一點可惜的是他最後一次更新是在 2019
接下來，我想要利用這個追蹤機制幫我完成資料表的部分更新，有異動的欄位才更新。
追蹤異動變化使用 ChangeTracking ，消化異動並存放到操作資料庫則使用 EF / EF Core，當然，這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
當有一個應用程序被用戶 ( SIGINT /Ctrl+C) 或 Docker ( SIGTERM / docker stop ) 停止時，它需要優雅地關閉一個長時間運行的工作；換句煥說，當應用程式收到關閉訊號的時候，要把工作做完，應用程式才可以關閉。微軟的 Microsoft.Extensions.Hosting 可以幫我們接收/處理關閉訊號，我們只需要告訴它要怎麼做就可以了，我在實作的過程當中，碰到了一些問題，以下是我的心得
.NET Core 1.0 開始為了跨平台重新改寫了 SQLite，名為 Microsoft.Data.Sqlite，刪除了過時的 DataTable 和 DataAdapter 相關的 DataSet API，這已經和之前的 System.Data.SQLite 不一樣，但團隊還是盡量讓它們兩者的 API 變化降到最低。這裡有官方的比較說明文件 與System.Data.SQLite的比較-Microsoft.Data.Sqlite | 微軟文檔
當我們要針對商業邏輯測試時，可能需要隔離 EFCore DbContext，搭配 Mock Framework 可以快速地建立測試替身假的 DbContext，自從 EF Core 的 In-Memory 出現之後，建立 DbContext 測試替身這件事，就變得輕鬆許多了
有天跟同事結對開發的時候，發現 EF6 新增後，會多一個 IDENTITY 欄位的查詢，經研究後發現這個是 EF 6 的特性，觀察了一下 EF Core 也有相同的特性
