2013-10-18 66 views
0

我有一個CQRS應用程序,事件存儲和讀取模型之間具有最終一致性。其中我有一個項目列表,並在列表下的「創建新的」按鈕。當用戶成功創建新項目時,他將被引導回列表,但由於讀取模型尚未更新(最終一致性),因此該項目在列表中缺失。如何在CQRS Web應用程序中爲用戶提供酰亞胺反饋

我想僞造列表中的條目,直到讀取模型已更新。 我該如何做到最好?如何在新項目出現在實際列表中時將其刪除?我預計閱讀模型的延遲時間大約爲60秒。

我意識到,沒有CQRS就有更簡單的方法來實現這種行爲,但應用程序的其餘部分真的從CQRS中受益。

如果它很重要,應用程序是一個c#mvc4應用程序。我一直在考慮涉及HTML5網絡存儲的解決方案,但想知道解決這類問題的最佳做法。

回答

1

在這種情況下,您可以完全置信地在UI中呈現結果。直接顯示此信息並從讀取的模型中讀取信息沒有區別。

您的域對象與UI最新,這是真正重要的。此外,如果您在每次操作中正確驗證AR狀態,並且跟蹤AR版本的併發性,那麼您就安全了,並且您的模型將受到保護以防止無效操作。

最後,你的UI不同步的概率是多少?如果您有許多用戶同時修改您顯示的信息,就會發生這種情況。這可以通過創建基於任務的UI並遵循規則'每個請求中的AR中的一個命令/操作'來避免。

只有在非正規化器完成他們的工作之後才能讀取模型。另一方面,如果命令會在傳奇和AR之間產生對話(長時間運行),那麼你不能這樣做,並且必須向用戶發出警告。

+0

謝謝你的回答@Alex。這幾乎是我和我的團隊也得出的結論。 AR縮寫是否代表Aggregate? –

+0

是的,聚合根(包括它的entites)...順便說一句,你使用哪個框架(如果你使用一個)「做」CQRS? –

+0

除了我們在這裏所說的,......這裏的主要觀點是,與使用CQRS獲得的收益相比,您在用戶界面中所面臨的風險很低,並且在某些情況下被允許。 請記住,在某些情況下,這種思維方式不會讓您擺脫改進UI以提高響應速度的責任。 –

0

我看到最終一致性僅適用於應用程序環境有多個託管應用程序的前端服務器,並且所有這些服務器都有自己的讀取模型副本。所有服務器使用相同的事件存儲副本。

當事件更改爲事件存儲時,讀取用於讀取結果的模型必須與事件存儲同步更新。其他服務器和由它們管理的讀取模型可以使用最終一致性進行更新。

通過這種方式可以從本地讀取模型副本讀取用戶(項目列表)的結果,因爲它已經同步更新。無需特殊複雜的假更新/回滾。

用戶只能看到不完整列表的情況是用戶在更新更改後點擊F5刷新列表,並且負載平衡將用戶請求引導至讀取模型尚未更新(60秒延遲)的前端服務器,但這可以應避免使負載平衡不會在會話中間更改用戶服務器。

所以,如果應用程序只有一個前端服務器,最終一致性是不是十分有用,或不無與讀取模型的一些特殊的假更新/回滾給出任何好處......

+0

我不同意這一點。最終的一致性與服務器數量或應用程序分發與否無關。一旦你有2個相關的模型是非同步的,但將來會同步,你有最終的一致性。 CQRS爲任何應用程序(大,小,本地或分佈式)提供了很大的靈活性,但是權衡是不得不處理消息驅動的架構怪癖:服務總線,冪等性和最終一致性。 – MikeSW

+0

是的,你說得對。我的觀點更多的是,當需要讀取數據時,應該以某種方式同步更新數據。我不推薦假冒更新,因爲它們給系統增加了不必要的奇怪複雜性。 – Harza

1

它不這是一個asp.net mvc應用程序。我看到的唯一解決方案,除了告訴用戶稍微等一下,還有還有一個,但是這次生成相同模型的同步事件處理程序(當然實際的模型生成應封裝在服務中)並將其發送出去到一個內存緩存。

內存中的所有內容使其非常快速且同步,意味着它在請求結束前自動執行。我假設這個命令也是同步執行的。

然後,在您的查詢存儲庫中,您還會考慮緩存的結果,如果該結果已由數據庫返回,則將其刪除。個人而言,對於我知道的事情,我希望對用戶可用,以及讀取的模型生成是微不足道的,我只會使用同步事件處理程序。用戶不介意在提交內容時等待幾秒鐘,如果更新讀取模型需要幾秒鐘,那麼您知道您有後端問題。

相關問題