在事件驅動架構中爲用戶提供即時響應

我一直在閱讀很多關於事件驅動架構的內容，這對我來說很有意義，但給用戶提供即時反饋的問題讓我感到困惑。在事件驅動架構中爲用戶提供即時響應

假設有一個服務（'EmployeeService'），它包含所有員工的列表。創建員工的業務邏輯位於此服務中。

來自其他系統的UI使用此服務。要求是（無論你是否喜歡）它有一個員工網格，還有一個「添加員工按鈕」，它會提供一個表單，當你提交表單時，它將把你帶回到新員工的網絡中它。網格顯示由服務計算的派生字段（這點很重要！）。

傳統上，在提交時，我會顯示一個加載屏幕，同步發送一個WCF請求來註冊員工，以及何時完成並轉發到網格（現在肯定會有新員工）。

隨着EDA，在提交時，我會「開火併忘記」一個命令來註冊用戶 - 但那又如何？我可以轉發到電網，但有可能新員工不在那裏？我可以手動添加到網格中，假設所有都是正常的，但是如何顯示服務計算的派生數據？或者，也許我可以在網格上顯示「新員工待處理圖形」（如果尚未創建），然後讓頁面檢查每一個secons，直到它具有？

這是一種常見的情況，所以常見的解決方案是什麼？

來源

2012-08-09 Paul T Davies

計算結果如此複雜嗎？通常需要多長時間來計算數據？ – 2012-08-10 05:07:42

@DanielMarbach它可能幾乎是瞬間的，但你無法保證它。 – 2012-08-10 07:50:49

如果你被固定到網格，那麼它可能不值得應用EDA原則。在這種情況下，RPC方法應該很好。 – 2012-08-10 12:40:55

發送命令和阻止時，您可以註冊回調，直到命令完成。

如果您已經下載NServiceBus軟件包，只需參考AsyncPagesMvc3示例解決方案。它有你正在尋找的一個例子。

來源

2012-08-10 02:59:42

我知道這個功能，但是這個請求/回覆風格應該在事件驅動架構中避免。 – 2012-08-10 07:50:20

鑑於您現有的需求，這是迄今爲止最簡單的解決方案。如果您有實時更新要求，並且不想遵循這種模式，那麼EDA可能不是一個好的解決方案，您可能想要遵循RPC樣式（至少在您操作的上下文中） – 2012-08-10 13:05:54

使用回調是一般是難聞的氣味。 NSB使其很難回到傳統的RPC式通信。嘗試堅持Pub/Sub。 – 2012-11-12 21:02:24

如果您的EmployeeService是一個SOA服務，那麼添加員工按鈕也屬於EmployeeService。用戶界面很簡單，是由多個服務組成的。您可以在處理員工創建和計算的客戶端本地部署EmployeeService部分（如果計算不是複雜的）。

例如：

public class AddEmployeeView 
{ 
    public IBus Bus { get; set; }  

    public void AddNewClicked() { 
     // async calculate 
     // store directly in the employee service database 
     // or dispatch command internally 
     // refresh employee list as the service is the only owner of that data 
     Bus.Publish<NewEmployeeAdded>(m => { }); 
    } 
}

所以上面AddEmployeeView屬於EmployeeService。僅EmployeeService知道如何計算和存儲新員工（即使在其自己的數據庫中），並且是NewEmployeeAdded事件的唯一邏輯發佈者。這裏消除了複雜性。

來源

2012-08-13 21:15:06

假設AddEmployeeView是網站的一部分，您如何處理髮布相同事件的負載均衡器背後的該視圖的多個實例？據我所知，這是不可能的和/或一個好主意。 http://www.make-awesome.com/2010/10/why-not-publish-nservicebus-messages-from-a-web-application/ – 2012-11-09 15:37:13

該網站可以向發佈NewEmployeeAdded的後端發送命令。 – 2012-11-12 21:01:44

在事件驅動架構中爲用戶提供即時響應

回答

相關問題