锁定商业模式

我有一个客户端应用程序在数据库中的“锁定”（又名“退房”某些商业实体店的必要性锁定商业模式

的工作流程是这样的：

用户导航到一些业务对象的页面。
用户点击“编辑”。
这从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

锁定商业模式

回答

相关问题