锁定商业模式答案

【问题标题】：Locking Business Model锁定商业模式
【发布时间】：2011-03-30 06:11:44
【问题描述】：

我有必要让客户端应用程序“锁定”（也称为“签出”某些业务实体存储在数据库中。

工作流程是这样的：

用户导航到某个业务对象的页面。
用户点击“编辑”。
这会锁定项目，防止其他人编辑。
其他工作站上的其他用户会在正在编辑的项目旁看到一个小的“锁定”图标，并且“编辑”按钮将是只读的。
管理员用户可以点击按钮“强制”解锁项目。

相当标准，对吧？我过去已经做过很多次了，我正在寻找关于这次“正确”做法的一些想法......

也就是说，我想有两种方法：

让我的业务对象实现一些具有 LockOwnerId 属性的 ILockable 接口，并让数据库中的相应表具有相同的 LockOwnerId。
在数据库中有一个集中的“EntityLocks”表，用于管理当前锁定/签出的所有实体类型/主键对。

关于获取锁的 API，我只是在想一些类似于 CheckOut 方法的东西：

// 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)

想法？

谢谢。

【问题讨论】：

我知道您说的是 WebApplication。那么这将是非常困难的。只是因为用户可以点击编辑并离开您的页面，并且在会话到期之前您永远不会知道它是否仍在编辑。至少在会话期间锁定您的实体。
更好的是，我说的是一个同时具有 Web 前端和 Silverlight 客户端前端（通过 WCF 与服务器通信）的应用程序。
这种模式称为悲观离线锁：martinfowler.com/eaaCatalog/pessimisticOfflineLock.html。

标签： c# .net database-design orm business-objects

【解决方案1】：

就个人而言，如果可以的话，我通常会尝试通过请求更改业务流程来远离这种模式。然而，这并不总是可行的，因此 Martin Fowler 将其描述为 an actual pattern.。

您描述的解决方案听起来不错。但是，我宁愿让CheckOut 方法抛出异常，除了返回bool。这要明确得多。当开发人员忘记处理这种异常情况（无法签出项目）时，错误将更容易发现（因为未捕获异常）。

另外，请注意CheckOut 方法的实现。确保它是事务性的。您最不希望看到的可能是两个用户都锁定了同一个对象，因为实现没有正确实现。

祝你好运。

【讨论】：