架構處理撤消和通知

Question

我目前正在設計一個複雜的網站，需要支持撤消和CRUD操作通知。

通過撤銷，我的意思是，用戶可以創建/修改/刪除的項目，然後決定取消他做了什麼（因此除去創建的項目，恢復修改項先前的狀態，或帶回刪除項目）。在完成該操作後，他可以在短時間內完成此操作（超時時間爲2分鐘，因爲系統相當複雜，用戶可能需要一些時間才能注意到修改不正確）。

通過通知，我的意思是當一個項目被創建/修改/刪除時，對該項目感興趣的其他用戶將收到一個現場通知（下一次他們加載一個新頁面），也將如果他們要求收到電子郵件或短信通知。

完成任一功能都很簡單：撤消涉及保留撤銷信息（主要是舊版本的修改或刪除的項目），而通知非常簡單，只需將通知對象推入相應的表格併發送電子郵件/短信在飛行中。

讓他們一起工作會產生很多額外的複雜性，因爲通知必須停滯不前，直到撤銷變得不可能，而且我沒有足夠的事後思考來設計它。

構建這樣一個系統時要避免哪些模式，最佳實踐或陷阱？

Answer 1

基於對思想和代碼的試驗，我設法提取了一系列原則。

• 用戶可以通過單擊取消按鈕或執行反向操作（如刪除他的評論）來取消操作。從通知的角度來看，沒有理由以不同的方式處理這兩種情況。
• 對於同時發生的同一對象的通知應該儘可能地組合在一起：顯示「A對您的帖子發表了評論」沒有意義......「Z對您的帖子發表了評論」，而不是「A，B ...和Z評論你的帖子」。因此，創建和刪除通知應根據分組規則分組在一起：如果它們足夠靠近在一起，則它們會互相取消。
• 由於取消的可能性，請勿立即發送通知電子郵件。等待兩分鐘。如果該操作被取消，則創建和刪除組規則將在尚未發送的通知仍在等待時刪除。當然，如果用戶目前已連接，您可以實時顯示通知，因爲與電子郵件不同，實時通知可以被「收回」。

基於以上原則，我決定架構兩個不同層上數據訪問層的頂部：

• 一組語義顯著操作，諸如「發佈新註釋」或「刪除評論「，然後通過有線發送通知。
• undo-enabled的定義操作對：「發表新評論」的「撤消」方面是「刪除評論」。

通過這種方式，操作總是通過基本操作集，從而觸發是不可知的它們是否受到取消先前的操作或手動運行它的逆運算—系統引起的通知巧妙地處理有關的多個通知通過將它們分組在一起並讓它們相互抵消而實現相同的目標。相反，「撤消」設施僅從語義層調用代碼，而不需要任何有關發送通知的知識。

顯然，仍然會有少量的耦合，因爲有時只需要添加一個語義操作，因爲它是現有操作的「撤消」反轉。例如，可以取消創建討論，但發送後不能刪除該消息（因爲可能會有回覆）。因此，cancelDiscussion函數可能存在deleteDiscussion不可用的地方。我懷疑這種情況很少得到安全接受。

Answer 2

我會考慮使用Command Pattern的撤消 （可能不會持續，直到超時過期） 和Observer Pattern的通知。編輯1：重新思考，我可能會立即堅持。否則，在超時過期之前，用戶會話的問題就會結束。

EDIT2：另一種選擇是使用Windows Workflow Foundation 4（WF4）和Compensation。建立一個長期運行的持久化工作流程作爲WCF服務。工作流可能只是一個WCF Receive活動來啓動它，一個Delay活動和一個自定義活動來發送通知;你可能甚至不需要一個CompensableActivity（如果延遲沒有過期，並且通知沒有被髮送，則沒有任何可撤銷的）。每個通知請求都會進行WCF調用以啓動新的工作流實例。如果用戶取消，則中止該實例。 （使用延遲執行Pick活動可能會更容易，而另一個WCF接收活動可以在調用時取消通知。）警告：我沒有實現像這樣的系統。