設計問題 - 使用事件，屬性還是不是？ （mvc）

Question

我想知道您對以下設計方案的看法。

我有一個'AgendaController'（.NET MVC項目），它處理用戶操作，如查看他們的議程，約會等等。當用戶進行預約時，約會被保存在數據庫中。然後，必須完成一項「次要」任務，在這種情況下，向用戶發送消息（無論是短信，電子郵件還是其他不相關的內容）。我可以用三種不同的方式實現這一點：

1. 我可以簡單地在控制器動作直接添加一個電話，像messageService.SendNewAppointmentMessage(data)。我想，這很好，雖然它確實讓控制器的操作變得混亂了一點。具體來說，如果由於某些未來的需求需要做某些其他操作（例如，日誌記錄雖然不是一個好例子），但我還是會再次調用某個記錄器類。

2. 我可以在AgendaController中聲明一個靜態事件OnAppointmentMade，並創建訂閱此事件的MessageService。然後，當約會被保存時，事件被觸發，並且實際的消息發送被處理在別的地方。如果這些要求出現，我可以有更多的課程訂閱這個活動。這樣，控制器動作保持非常乾淨，所有的「次要任務」都在其他地方執行。

3. 我可以在控制器動作[SendNewAppointment]上使用自定義屬性，並在該屬性的OnActionExecuting方法中發送消息。這很好地遵循MVC設計我猜，但我不一定喜歡屬性混亂：我會有一個Authorize,AcceptVerbs,ActionName,SendNewAppointment等etc屬性在一個單一的控制器操作。

哪個設計是首選？哪一個肯定是不行？我對第二個設計略有偏好，但我不知道是否應該（事實上）使用這個事件。我真的很想聽聽你的意見！

Answer 1

就我個人而言，我稍微優先考慮第一個選項，因爲它是最可測試的選項。

第二個選項也很好，但我不喜歡靜態事件的想法，因爲靜態的一切都很難測試（我不是說不可能，只是更難）。

Udi Dahan最近發佈了一篇關於Domain Events的文章，它類似於你的第二個選項，他很聰明，所以值得考慮。就個人而言，我仍然傾向於將事件經紀人（本質上是調解員）作爲實例傳入的變體，但總的想法依然存在。