過去的工作專案為了要加快 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
在去年 10 月寫了這一篇文「Repository 測試使用 Testcontainers」，不過文章裡只有公開部分的程式碼類別，可能會讓有些人想跟著實做卻會遇到做不出來的狀況。
但因為實際的程式原始碼已經不在了，所以我就重做了一個新的專案，盡量還原當時的範例專案，之前文章裡的測試專案是使用 MSTest，而這個新建立的專案則是提供了 xUnit 與 MSTest 兩種測試專案，讓使用這兩種測試框架的開發人員可以參考。
一般來說建立 RabbitMQ Cluster 最快的方式就是透過 Docker 建立，看你是要直接下指令或是編寫 Docker Compose 檔案後再執行都可以，但是會遇到一個問題就是叢集環境建立完成後，還需要再進入 RabbitMQ Management 裡去逐一建立 vhost, User 等等的設定，好一點的話就是有事先匯出一份 definitions.json，這麼一來只需要匯入這個定義檔就可以完成了。
但如果是對一個 Docker 不熟悉更不用說去輸入一條條的指令和一連串步驟的新人來說，上面所說的對他們都是充滿著挑戰性，於是就將建立開發環境 RabbitMQ Cluster 的過程都寫成一個 bat 檔案，新人只要在自己電腦裡安裝好 Docker 環境後只需要執行這麼一個 bat 檔案就可以完成 RabbitMQ Cluster 的建立，裡面所有的設定也都準備好，馬上就可以應用在專案開發上。
