等待併發送一批保存的命令

我有一個WPF應用程序連接到遠程後端：用戶可以在GUI上編輯許多不同的元素，但決定只在應用程序關閉時保存或放棄。該GUI支持撤銷/重做。等待併發送一批保存的命令

我已經跟蹤每一個編輯和保存時生成必要的命令到後端執行編輯：我的命令是一樣的東西：

public class ChangeDescriptionOfTypeAObject 
{ 
    public string OldValue{ get; set; }  
    public string NewValue{ get; set; } 
    public string ObjectID{ get; set; } 
}

這個工程在當前的應用程序，但我在想命令失敗，如果另一個用戶在此期間改變相同的屬性。可能我必須向用戶發送一條消息：「對對象ObjectID的描述更改無法應用：當前值爲xxx」並應用所有其他更改。

這是一個正確的方法嗎？如果我用來檢查「CurrentValue == OldValue」的讀取模型是否正在從另一個用戶更新，那麼如何才能確保可以在最終一致的過程中成功應用命令？

來源

2014-09-23 Mauro Destro

我認爲這取決於 - 國際海事組織最好的辦法是讓* events *和* commands *小於你所做的，併爲它們帶來某種併發檢查（通常只是一個版本號） - 然後在更新之前可以再次請求當前狀態，如果所有其他都失敗了，後端會給你一個併發檢查 - 我不認爲你真的可以避免這種情況，沒有一些鎖 – Carsten 2014-09-23 11:03:20

爲了讓這個更清楚一點：後端必須檢查一致性！（前端也可以檢查，但後端必須有最後說） – Carsten 2014-09-23 11:04:53

我對你的問題的理解是你需要很好地理解和應用optimistic concurrency，當你使用最終的一致性時，這真的被推薦。

對於CarstenKönig是正確的，您需要跟蹤您想要更改對象的方式，以瞭解是否有人在將其保存在後端時進行更改。這可以通過版本號完成，MSDN建議使用TimeStamp。

無論如何，重點是您需要檢查只有一個用戶在保存時更改對象，或者至少應用於對象的更改與其他更改沒有衝突。否則，您需要提出錯誤並通知用戶更改無法保存（或提供某種合併過程）。

用戶可以編輯GUI上的許多不同的元素，但決定保存或放棄只在申請截止

的問題，此方法的缺點是它不與樂觀併發真正兼容，因爲修改對象所需的時間越長，您最有可能與其他用戶更改產生衝突的機會最大。「管理撤銷/重做」功能並不是恕我直言，不會盡快通知服務器這些變化，除非您對服務器的通信有一些限制。

我看到三個解決方案，這取決於您的上下文：

如果它是可以接受的域名，可以使用悲觀併發（即鎖定在你的UI數據管理），只要用戶不關閉你的應用程序（顯然它是一個不可擴展的解決方案），並保持你當前的撤銷/重做管理。
否則，如果需要可擴展性，使用樂觀併發，因此寧願不發到底的所有數據，但每次更改模型後（並管理在服務器端的撤銷/重做過程）
或者讓你當前的實現，加上樂觀併發，併爲您的用戶提供一些合併方案如果同一對象的多修飾經常發生

希望它能幫助。

來源

2014-09-23 13:08:49 Ouarzy

我明白，但對於命令處理方面：我必須從保存的事件中重建我的對象，這些事件可能會丟失正在進行的最新事件，或者我錯過了一些已知的？ – 2014-09-23 14:45:55

對不起，我不明白你的意思？你的對象是在查詢期間創建的（當你創建你的UI時）。所以當你發送一個命令來更新這些對象時，你需要檢查他們沒有被修改到別的地方。 – Ouarzy 2014-09-24 07:33:06

等待併發送一批保存的命令

回答

相關問題