锁定老帖子 主题:工作流活动实例状态转换的两种实现模式
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|||
---|---|---|---|
作者 | 正文 | ||
发表时间:2007-10-28
作者:胡长城 今天和同事chelsea 就活动实例状态的实现思路上进行了讨论。我们两个站在了两个不同的角度来看待,这两个不同的角度也正好眼下最为常见到的两种实现思路: Chelsea是从状态角度来看待,当然也完全是从state pattern的角度来思考:状态在达到某个状态的时候,会引起或必须引起活动实例执行什么操作。 而我是从活动实例的角度来考虑,活动实例的状态只是活动实例的一个属性体,是因为什么行为,造成了什么状态的结果。 <o:p> </o:p> 这两种观点,没有谁对谁错,也没有谁优谁劣,两者是站在不同的角度来分析同一个问题。其实这两种模式在应用中都是很普遍的,也都是能够很好的解决问题的。不过在现有的workflow引擎实现中,基于活动实例的角度是占绝大多数的,比如obe,shark等等。所以我受这个的影响也是比较深的。 <o:p> </o:p> 先说说基于活动活动实例的角度的思路吧: <o:p> </o:p> 让我下先来看看状态类:
<o:p> </o:p> 对于活动实例来说,状态只是其一个属性而已:
<o:p> </o:p> 所以,从活动实例的角度来看,状态之间的关系是平行的。你可以在执行完一些初始化的操作之后,将活动实例的状态设置为Initialized:当然这个操作你必须显示的去设置活动实例(当然,你可以用一些Event去处理),比如调用活动实例的setState方法。至于为什么调用这个方法,或者此时设置的状态是对是错,活动实例并不关心。 <o:p> </o:p> 下面再来说说基于状态角度的思路吧,这个思路大体可以说就是state pattern的应用。 <o:p> </o:p> 说道这儿,您可以看看这篇文档:从工作流状态机实践中总结状态模式使用心得 。当然如果您对state pattern不是很了解,那么建议你先看看这篇文档:设计模式之state 。<o:p></o:p> <o:p> </o:p> State模式的着眼点就是状态,以状态的变迁影响实例的行为和动作。其实这就是两个不同的抽象体:state和stateOwner,我们可以看到,活动实例对象就表现为stateOwner。<o:p></o:p> State模式的依据是状态之间是有有向连接关系的,这有向连接关系其实就是状态的转换规则:A-B-C-D-A。 激发状态的变迁,是由外界的事件(Event)影响的:这个事件会告知,当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么,这完全是状态对象负责维护和告知的。
至此,我们可以看出来了,两种方式的不同: 第一种方式(基于活动实例),其外界事件是影响到活动实例,或者说在事件中显示的告知活动实例状态从什么变为什么。 第二种方式(基于实例状态),其外界事件是影响到活动实例状态对象,至于这个状态的下一个状态是什么,时间并不知道,完全由活动状态之间的关系来维护。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|||
返回顶楼 | |||
浏览 1974 次