鎖定商業模式

我有一個客戶端應用程序在數據庫中的「鎖定」（又名「退房」某些商業實體店的必要性鎖定商業模式

的工作流程是這樣的：

用戶導航到一些業務對象的頁面。
用戶點擊「編輯」。
這從anyo被編輯，鎖定該項目別的。
其他工作站上的其他用戶將看到正在編輯的項目有一個「鎖定」圖標，「編輯」按鈕將是隻讀的。
管理員用戶可以點擊一個按鈕來「強制」解鎖項目。

很標準吧？我這個做了一堆的時間過去，我找的一些想法做這這一次的「正確」的方式...

也就是說，我想有兩種方法：

我的業務對象是否實現了一些具有LockOwnerId屬性的ILockable接口，並且DB中的對應表具有相同的LockOwnerId。
在DB中有一個集中的「EntityLocks」表，用於管理當前鎖定/檢出的所有實體類型/主鍵對實體。

至於獲取的鎖，我只是沿着檢驗方法的思路思考的東西API：

// Returns true if the check-out was successful, 
// false if the check-out was not successful, becase the item was already locked. If 
// force is set to true, will check out the toCheckOut to the current user, regardless 
// of existing check-outs. 
bool CheckOut(object toCheckOut, bool force)

的思考？

謝謝。

來源

2010-08-16 Jeff

我明白你正在談論一個WebApplication。那麼這將是非常困難的。只是因爲用戶可以點擊編輯並導航離開您的頁面，並且您將永遠不會知道它是否仍在編輯，直到會話過期。至少在會議期間鎖定實體。 – Jeroen 2010-08-16 04:08:10

更好的是，我正在討論一個具有Web前端和Silverlight客戶端前端（通過WCF與服務器通信）的應用程序。 – Jeff 2010-08-16 04:14:08

此模式稱爲悲觀離線鎖定：http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html。 – Steven 2010-08-16 06:16:08

就個人而言，如果可以的話，我通常會嘗試遠離這種模式，通過請求更改業務流程。然而，這並不總是可能的，因此Martin Fowler將其描述爲an actual pattern.。

您描述的解決方案聽起來很好。但是，我寧願讓CheckOut方法拋出異常，除了返回bool。這更加明確。當開發人員忘記處理這種特殊情況（該項目不能被檢出）時，該錯誤將更容易被發現（因爲該異常未被捕獲）。

此外，請妥善保管CheckOut方法的實施。確保它是事務性的。你想要的最後一件事是兩個用戶都可能鎖定同一個對象，因爲實現沒有正確實現。

祝你好運。

來源

2010-08-16 07:17:22 Steven

鎖定商業模式

回答

相關問題