基于WF设计业务流程平台-架构
最近不少朋友询问我关于用WF设计业务流程的问题,看来很多朋友已经从对WF的了解学习阶段进入到WF的开发阶段,所以在我准备写一组业务流程平台设计的文章与大家交流一下这几年我开从事工作流开发的一点经验
很多人一提到WF就想到工作流,一提到工作流就想到审批,所以不少人认为WF是做审批系统的.这种说法就象是说C#是做审批系统的一样,不能说不对,但很片面.
个人认为WF是继面向对像编程,可视化编程后又一重要的里程碑,WF体现了一种执行逻辑与实体对像分离的设计思想,面向对像的设设计思想体现了实体对像间的静态关系,而WF则提供了这些实体对像在相互做用的过程中的态关系.在今后的发展中,WF是否可以完成这个使命不好说,但WF以对编程思想的影响绝对不会仅仅是一个审批系统的开发包, 以上只是个人观点,而且也不是本文要谈论的内容,仅是学习了3年多WF的一点感受.
个人认为WF提供了非常多的功能,基于这些功能实现业务有多种组给,没有必要追求在应用中要使用WF的全部功能,也没的必要追求一个完美的架构,个人认为适合就好.
就我个人的经验用WF开发
-
业务流程平台
-
工控系统
-
数据服务的逻辑算法
-
应用软件的执行逻辑控制
这几方面都是非常棒的,但不同的应用,所设计的架构与用到的技术是不一样的.
本文是一个我经常使用的业务流程平台架构(审批类系统,有三个独立的项目用的都是这种架构).
使用XOML格式的工作流模板
WF提供了两种方式的工作流模板,Dll方式与XOML方式.当然你可以实现Load让引擎支持Visio或其它任意.
很多第一次开发WF项目的人都选用Dll方式的工作流模板,原因主要是因为用Dll方式比用XOML方式简单
另外使用XOML方式也有两种,一种是编译XOML方式一种是加载XOML方式.
编译XOML与加载XOML方式的XOML文件与实现原理有很大的不同,我以前的文章的详细的描述,这里就不再说了.
本架构是使用加载XOML字串的方式
在这里要说明一下用DLL模板与XOML模板的优缺点
性能,兼容性等套话就不说了.如果要实现同一业务,DLL模板与XOML模板的比较如下
DLL模板:开发人员省事,用户要设计流程费事
XOML模板:开发人员费事,用户要设计流程比较省事
如果你要觉得很难取舍,最好的方式就是两种方式都支持,比如SharePoint3.0 的工作流,用SharePointDesigner设计的流程就是XOML格式的,用VS设计的流程就是Dll格式的
还有,用XOML字串模板,有一个问题就是无法在工作流中写代码,这个问题在下节[自定义与XOML工作流的结合]中将讨论
自定义与XOML工作流的结合
用XOML字串模板,是无法在工作流中写代码,很多时候我们需要在流程中添加代码,用XOML字串模板是不允许这样做的,我的解决方案是将代码封装到自定义的Activity中,并编译成DLL库,然后在XOML字串模板中引用该自定义的Activity
这里有一个问题,就是自定义的Activity与流程以及其他自定义的Activity的通信问题,好在WF提供了DependencyProperty,我在以前的文章里详细的讲过用DependencyProperty实现上下文解决自定义的Activity与流程以及其他自定义的Activity的通信问题,这里就不再描述了.
业务流程的状态维护
WF提供了队列查寻,跟踪查寻,这些都是WF的状态维护接口,不过这些接口是系统级的,我个人觉得自定义一个业务状态表还是有必要的.
业务状态表的结构本文先不讨论,下面是工作流实例与业务状态表的交互说明
系统的物理结构
最后,我们要为WF服务选一个宿主以及WF服务与外部通信的方式,我个人不建议在IIS的Application中缓存WF服务这种方式,我常用Win服务与WCF实现,
对于这两种方式的优缺点,我不加评论.如果对Win服务与WCF的开发不熟悉,我建议学习一下这方面的知识
下图是我常用的一种方式:
