之前寫了一篇「使用 Channels 與 BackgroundService 實作生產者-消費者模式（Producer-Consumer Pattern）」是使用 Channels 與 BackgroundService 來實作，而這一次就來改用 Wolverine 這個套件來試試看。
有關 Wolverine 這個套件我也看了好久，一直想拿來試試看，會想要用這個套件，主要是它是一個輕量化的工具，適合用於整合訊息佇列、事件驅動設計和後台任務處理。
而且也因為適合用於整合訊息佇列、事件驅動設計，所以支援了許多第三方服務，例如：RabbitMQ, Kafaka, MQTT, AzureServiceBux, AmazonSqs 等，所以打算之後也繼續玩玩 Wolverine。
從 .NET Framework 開發 WebApi 服務時就開始使用 Swagger UI，直到現在都已經是直接在預設的 ASP.NET Core WebApi 專案範本裡就包含在內。
但是… 我一直都覺得 Swagger UI 做為 API 文件工具並不是很好閱讀，要查看輸入參數或輸出資料格式內容都不是那麼方便，我想大家或多或少應該都有這樣的感覺，所以我都還會在專案裡安裝 ReDoc 套件，ReDoc 做為 API 文件工具來檢視 API 的輸出入各種資訊都相當直觀且清楚，比 Swagger UI 更好閱讀，但是 ReDoc 只是個單純的 API 文件檢視工具，無法在 ReDoc 裡測試執行 API。
所以之前看到 Scalar 這個新的 API 文件檢視工具時就讓我眼睛一亮，有著如同 ReDoc 一般的 UI 外觀，可以方便且直覺地查看 API Endpoints 的資訊，而且還可以直接在上面測試執行 API，所以就趕緊來試試看。
過去的工作專案為了要加快 Request 的回應速度，所以就想方設法地去做了很多的調整…
例如一個訊息建立後要做很多的事情，像是要許多相關資料 Table 的資料異動、透過 RabbitMQ 去發送 message 通知其他 Client、快取資料的更新等等等
這麼多的處理如果都是在一個 Request 裡全部處理完成後才回傳 Response 結果，因為每個處理都會花費一些時間，全部累積起來就相當可觀，於是就會想到是不是要往平行處理或多執行緒的方式來解決，但是在繁忙的網站服務去使用這些解決方案又有很多風險，程式沒有寫好的話就會出現嚴重錯誤。
所以就想到用發送事件的方式，當訊息建立完成後，就發送一個事件到一個佇列裡，然後有一個 BackgroundService 去專門接收訊息建立完成事件，當收到事件後就開始一連串的處理，這麼一來 Action 方法的回應時間就能夠加快一些。
上一篇「背景常駐執行計時工作 - 使用 BackgroundService 與 PeriodicTimer」介紹了使用 BackgroundService 與 PeriodicTimer 實作計時的工作處理。
但如果有時候一些工作處理並不是每幾秒鐘或每幾分鐘、每幾個小時這樣的週期行為時，使用 PeriodicTimer 就無法滿足這樣的需求，而在使用 Hangfire 建立 Recurring Job 時都會使用到 Cron Expression 去定義工作的執行週期，而就有看到這麼一個 NuGet 套件就有提供這樣的功能，所以就拿來試試看。
背景常駐執行計時工作的實作方式有很多種，而我習慣在 ASP.NET Coe Web Application 使用 BackgroundService 然後搭配 Task.Delay 的方式來完成計時執行工作的處理，而在 .NET 6 提供了 PeriodicTimer 後就可以更方便的處理計時工作，這篇就來認識執行計時工作的幾種實作方式。
前一篇文章「練習題 - 設計模式 - 責任鍊模式 (職責鍊模式) Chain of Responsibility Pattern」是不藉助任何套件的方式下完成實作，但我總會想應該是有人會做個 NuGet 套件來讓開發者可以直接套用就能夠完成責任鍊模式的實作，找了一輪後發現到還蠻少的，雖然少但也還是有一些，不過有的是已經很久沒有更新或是用的人不多，而有些是不適合真的拿來使用，有這種情況大概是責任鍊模式的實作其實並不複雜。
不過還是有找到一個還可以的套件，所以就拿來用在之前的練習題裡，看看是不是適合。
工作專案裡並不會去刻意地去使用設計模式，不過在很多時候為了想要有更好的實作，又或者是覺得當下的程式一定會有更好的解法，就會去找目前情境所適合使用的設計模式來改寫。
有的時後會看到誤用了不適合的設計模式所實作的程式，明明應該是用行為類的設計模式來做，卻用了結構類的設計模式來做，雖然最後的執行結果是有符合預期，但怎麼看就怎麼怪，所以設計模式還是要好好地認識認識，於是這次就來練習練習責任鍊模式。
前面分享的兩篇文章，分別介紹了 Microsoft.Bcl.TimeProvider 和 AutoFixture 的 AutoData
另外在寫測試時，可以使用 FakeTimeProvider 去做抽換，就可以設定時區、時間來完成測試情境的執行。
那麼是不是也可以用 AutoData 的特性，讓我們在寫測試的時候可以省下建立 FakeTimeProvider 的步驟呢？當然可以，不過需要先瞭解該怎麼做、可以怎麼做以及應該如何做。
這是一篇借花獻佛、拾人牙慧的文章，之前有寫過這麼一篇文章「單元測試使用 AutoFixture.AutoNSubstitute」
當時是使用了 AutoFixture.AutoNSubsititute 來減少測試類別裡相依類別的 Stub 建立步驟，用了很奇怪的方式來解決我當時的煩惱。
直到我進入到另一個團隊後，才知道可以藉由 AutoFixture.AutoData 做到更為簡單與彈性的解決方式，這篇就來簡單介紹怎麼做。
我想很多人看到標題後都會直接想
「程式裡直接用 DateTime 難道錯了嗎？」
「DateTime 用得好好的，為什麼要改用 Microsoft.Bcl.TimeProvider ?」
「我又不必寫測試，我就是要用 DateTime！」
我也管不著各位想怎麼用、想怎麼寫程式，只是看到很多有關於交易處理的程式都是跟時間判斷有關，而且有著種種原因而沒有寫測試，就讓人覺得那些產品妥當嗎？
而且一遇到 DateTime 的處理，就會卡在不知道如何寫測試。
所以就來寫這一篇簡單介紹 Microsoft.Bcl.TimeProvider