换一个角度再谈一下WF
换一个角度再谈一下WF
使用WF可以开发两类流程
- 业务状态流程
- 功能控制流程
业务状态类流程
是传统意义的工作流平台所提供的流程,特点是用流程进行业务的状态处理
关于这方面的例子我已经写过很多文章了,本文就不再谈这方面的内容了
功能控制类流程
在这里先对功能控制类流程做个说明
举个例子:
我们先对A表进行数据操作,再对B表进行数据操作.如果操作B表失败,则回滚对A表的操作.
当然,看到这里你会说这不就是数据库的事务处理吗.是的没错,那我们将上面操作的复杂度提升一下
如上的流程就是,功能控制类流程
他的做用不是置状态,而是完成一组后台的操做.
当然,你也可以用存储过程完成这个操做,但如果流程中还有对磁盘的操做,对网络的访问,对外部设备的控制,用存储过程做就力不从心了
在WF中,内置了很多对为实现功能控制类流程而提供的功能,有网络通信类的Activity,有对事务,补偿的支持.
在WF出现前,要实现上述业务,我会使用COM+
COM+是一个组件服务的容器,虽然NET可以开发COM+应用,但从本质上说是NET使用旧的技术,
NET推出后,
ActiviteX,COM向NET的组件过渡
DCOM向Remoting过渡
而COM+ 一直没的NET的方案,虽然Remoting提供了COM+的一些功能,如组件服务,远程事件,单例组件等,但对放入Remoting中的多个组件的上下文管理,事物,补偿等功能,Remoting却不直接提供.
而WCF + WF 的组合,可以说是COM+ 向 NET 过渡的一种方案.
注:以上说明并非MS的官方说明,只是我个人的感觉,全当给大家一个参考
COM+ 的问题先不谈了,我以后发几个同一业务分别用COM+ 与 WCF + WF 的对比方案.
我们回到WF的应用上,
在设计WF流程时,我不建议如下方式设计流程
上面这个流程将[业务状态流程]与[功能控制流程]混到一起了
其实[功能控制流程]应该是[业务状态流程]的底层
所以我修改设计如下
在实际的设计方案中,我一般是这样做的
最后再补充一点题外话
最近有不少人对我说,听说NET 4.0中WF的变化很大,…………
NET 4.0中WF我没见过(以前装了个CTP,别人告述我其中的WF是旧的)
不过我猜想新的WF一定会在[状态控制]与[应用功能]两个方面增加功能.
在[状态控制]上,可能会添加对[流程图],[状态图],[时序图],[Petri网]等流程设计上的支持,就算4.0不提供,5.0,6.0,7.0总会提供的
在[应用功能]上,可能会添加大量的功能Activity,具体有什么就不好猜了,磁盘IO类,Windows服务管理类,SQlServer操作类,SharePoint操作类,篮牙通信类,都有可能
为什么会这么零散,因为WF的全称是Windows Workflow Foundation
另外,我对WF还有一个假设
WF会退出[业务流程平台]的舞台,这里我指的退出是指不直接用WF开发[业务流程平台],而是
[WF] -> [业务流程SDK / 产品] -> [业务流程平台]
其实在WF推出后,我就猜想MS会将WF与其某款Server产品结合实现[业务流程SDK / 产品],
我当时猜想会是Exchange Server,没想到看走眼了,竟然是SharePoint .(这里我们先不提CRM与BizTalk)
SharePoint与WF结合的市场反映怎样我不加评论.反正我是不用!
我猜想在WF 4.0 后,MS会出一款直正的[业务流程SDK / 产品],可能是一个脱胎换骨的SharePoint,可能是Exchange,可能是一个全新的XXX
会不会是BizTalk呢,我觉得可能性不大,因为一个是后台算法Server,一个是前台业务Server,这样不是更好
以上的分析,不管对错,全当是一种参考吧