这一篇我把WF中有关数据处理的操作完全交给WCF处理,WF只关心流程的设计处理,至于底层数据如何操作并不需要关心。这在很大程序上减少了应用程序之间的耦合度。
SendActivity:客户端活动,用于模拟 WCF 服务操作的同步调用。
在WF中可以利用SendActivity完成对WCF的调用,不需要用传统的方式,先生成一个WCF代码,然后调用相应的方法。在项目中我们触发外部事件是靠"HandleExternalEvent activity",在事件中写相关的业务逻辑代码,觉的耦合度高了点,因为WF不光要设计工作流,而且需要和数据库打交道。
解决方案:在HandleExternalEvent activity后面加上一个SendActivity,此时HandleExternalEvent的事件的唯一作用就是给SendActivity参数赋值。由于项目中的状态比较多,我展示员工状态的活动图:
SendActivity属性设置:
1:ChannelToken:SendActivity 在建立其自身与客户端通道之间的关联时所使用的 ChannelToken。
2:Name:获取或设置此实例的名称。此名称必须符合工作流项目中使用的编程语言的变量命名规则。
3:EndpointName : 用于与服务通信的Endpoint 。
4:ServiceOperationInfo:WCF服务接口。
5:OwnerActivityName :关联的 Activity 的名称 。
6:Parameters:方法中的参数。这个参数需要后台代码支持,这里分为两步:
第一:创建一个新的成员:
public static DependencyProperty sendActivityValueProperty =
DependencyProperty.Register("sendActivityValue",
typeof(ExpenseAccountInfo),
typeof(ApproveWorkFlow.MyWorkFlowStateMachine.Workflow1));
[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)][BrowsableAttribute(true)]
[CategoryAttribute("参数")]
public ExpenseAccountInfo sendActivity1Value
{
get
{
return ((ExpenseAccountInfo)(base.GetValue(Workflow1.sendActivityValueProperty)));
}
set
{
base.SetValue(Workflow1.sendActivityValueProperty, value);
}
}
第二:设置参数,如下图:
最后的 SendActivity属性设置界面如下:
WF代码的变化:员工的事件代码如下,会发现已经没有任何有关业务逻辑的代码,仅仅是给一个属性赋值。所有的通信操作都交给SendActivity去完成。
{
info = e as ExpenseAccountInfo;
sendActivity1Value = info;
}
启用WCF后的网站结构的变化:网站的UI(网页层)在处理审批流程时,只和WF沟通,WF只负责流程处理,并不关心数据处理过程,WCF完成WF发来的请求。 改造前的WF即要设计审批流程,要又负责数据处理。
最后说一个下调试:在WF中应用WCF,最关键的一步就是添加一个WCF的引用,如果这个WCF是在IIS中,也就是说地址是固定的,添加完引用后,如果我们是直接按F5运行解决方案,此时会应用程序会动态分配一个端口,这样在生成代理类后,endpoint并不是配置文件中的,我的解决方案就是直接添加项目中的WCF,然后将WCF与WEB程序同时启动,即多项目启动,这样就可以调试到服务端了。或者是网站程序也放到IIS中,从IIS中打开网站,这样就避免了动态应用程序端口带来的问题。
本文引用:http://www.cnblogs.com/foundation/archive/2008/05/23/1205430.html