前段时间用m$的WF用了很长一段时间，并拿来做过一个半项目（后半个半途由同事接手了），对于WF的编程模型稍有些感触，在近期手上的一个项目中，涉及到流程的地方也有很多，本来也想将WF应用其中，但考虑到安装个.net 3.0 Fx就非常之麻烦，部署到客户的服务器上，还不得让客户烦死 :)
所以思前想后，还是自己模拟一个简单的得了。
先说说我对WF的理解(主要偏向于状态机工作流)，再来说我的mocking-WF
WF的核心是WorkflowRuntime，该运行时用来管理所有工作流实例的状态流转，生老病死；同时，WF提供了一个ExternalDataExchange属性用来外界跟WorkflowRuntime进行，交互以接口方式进行，即针对一个可能的状态定义一系列相对应的事件接口，由外界调用，同时，WF也提供一个Channel和相应的Service用于数据的持久化操作，具体可参见SqlPersistenceService的实现，以及我前几篇blog中提到的FilePersistenceService实现。
为什么在WF的帮助下，流程设计可以自由灵活的改变？无非就在于工作流运行时对工作流定义的实时解析，将下一可能的状态反应到TrackingService中，我们便可借助TrackingService获取到相应可能的接口方法。
针对WF的这一特点，为了我手头上项目也有一点工作流的”味道“，我实现了如下一个demo
在类图中，Definition<Tstate>是所有状态定义的基类，向外界提供其内部状态定义，供解析之用。CardDefinition&ScheduleDefinition是两个具体的实体状态定义；StateParser<Tstate>用来解析Definition<Tstate>对象中的状态链表；所有的状态均以枚举形态出现。
在StateParser<Tstate>中提供的解析方法如下：
public bool Parse(Tstate curState, Tstate targetState) //参数为当前状态，期望达到的末状态
在该方法内部会根据当前Definition状态链表定义，判断参数中提出的状态跳转是否合法，以布尔值形式告知调用者。
客户端调用如下：
StateParser<ScheduleStates> sp2 = new StateParser<ScheduleStates>();
sp2.StateDefinition = new ScheduleDefinition();
Console.WriteLine(sp2.Parse(ScheduleStates.Inited, ScheduleStates.Created));
具体的实现还是得看代码，点这里 :D