WF学习笔记——开发基础

目录

一 传递参数

二 执行上下文

三 状态图建模

一 传递参数

(一)工作流与宿主间的参数传递

  参数定义为工作流类中的属性,可以是普通属性也可以是依赖属性,具体区别会在之后讨论。

  如果定义普通属性,其代码形如:

    public double Left { get; set; }     public double Right { get; set; }     public double Result { get; set; }

  向工作流传递参数,其代码形如:

    Dictionary<string, object> wfArgs = new Dictionary<string, object>();     wfArgs.Add("Left", 1);     wfArgs.Add("Right", 2);     WorkflowInstance workflowInstance = workflowRuntime.CreateWorkflow(typeof(WorkflowLibrary.Workflow), wfArgs);

  获取工作流中输出参数的属性值,其代码形如:

    (double)e.OutputParameters["Result"]

(二)依赖属性

  依赖属性的属性值存储在一个中央存仓库中(类似字典),而不是实现为类中的普通实例变量。依赖属性与普通属性的主要区别在于允许在运行时绑定属性值到实例数据。通过绑定可以将活动A的属性绑定到活动B的属性上,或者绑定到工作流的属性上(工作流使用普通属性即可)。由绑定所产生的属性实际值是在运行时确定的,在定义自定义活动时,经常会使用依赖属性。

  VS内置依赖属性的实现模板:

  代码形如:

WF学习笔记——开发基础_第1张图片

(三)绑定

  想要将活动A的属性赋值给活动B的成员或者工作流的成员,需要通过绑定来间接地实现。绑定可以声明性地处理传值,而无需使用代码显式地赋值。绑定使用System.Workflow.ComponentModel.ActivityBind类定义。

1 在设计器中绑定

WF学习笔记——开发基础_第2张图片

2 在代码中绑定

  查看工作流的后台代码我们可以看到VS是如果使用代码来进行绑定的,其代码形如:

System.Workflow.ComponentModel.ActivityBind activitybind3 = new System.Workflow.ComponentModel.ActivityBind(); activitybind3.Name = "Workflow";//对象名称
activitybind3.Path = "Right";//对象成员
this.sumActivity1.SetBinding(ActivityLibrary.SumActivity.RightProperty, ((System.Workflow.ComponentModel.ActivityBind)(activitybind3)));//绑定

  一般不需要我们显式定义绑定,流程设计器会帮我们生成相关代码。

3 在配置文件中绑定

  WF支持在配置文件中设置绑定,但是笔者没有尝试,如有需要请参考MSDN关于WF配置节的文档。

二 执行上下文

  每个活动的执行都伴随着一个执行上下文(包含一个或多个活动的执行语境),它提供了安全引用父活动和子活动的机制。执行上下文用ActivityExecutionContext表示,其主要作用于3个方面:

  • 持久性 执行上下文提供了一个用于存储工作流状态的容器。
  • 循环 WF内置的循环活动(ReplicatorActivity、WhileActivity和ConditionActivityGroup)用于多次执行子活动。本质上,循环活动会创建循环体内部的子活动副本,并执行这些副本(深复制)。
  • 补偿 活动的每次执行都伴随执行上下文,使补偿可以获取已完成活动的一系列操作,以帮助补偿来恢复活动状态。

  多数时候,执行上下文不需要我们显式调用,但是,我们需要在以下3个方面考虑使用执行上下文:

  • 在循环中访问子活动
  • 编写规则
  • 开发自定义活动

  在之后的博文中,笔者将给出实例代码,本文不做探讨。

三 状态图建模

  本节将简单介绍UML中的状态图建模知识。也许读者可能认为,UML已经超出了WF开发的范围,但笔者认为,熟悉状态图建模是开发状态机工作流的基础。而UML状态图的绝佳的入口点。

  状态图在UML中用于建立动态模型。状态图用来描述对象、子系统、系统的生命周期。下图显示了一个表单审批的业务模型:

WF学习笔记——开发基础_第3张图片

  从上图可以看出,当用户填写申请时,表单处于“新建”态。填写完成并送签后,表单变为“流转”态。在审批人处理前,申请人,还可以撤销本次申请,此时表单再次变为“新建”态。在表单审批过程中,常规的送签和退回操作不会改变表单的“流转”态。但是,当最后一级审批人审批完成,或者某个审批人进行了报废操作,则会分别导致表单变为“办结”态和“已作废”态。可见,状态图关注的是状态间的转换,因此,我们在绘制时首先应该识别全部目标状态,然后考虑状态间的转换事件。

你可能感兴趣的:(学习笔记)