基于WF的工作流平台（二）：系统架构

前面我们谈到WF已经实现了工作流平台的最难的引擎部分，但为了这个引擎的通用性，他的编程接口比较复杂，并且和应用领域相关的部分也都没有实现，所以我们必须首先实现一个工作流平台，在这个平台之上才能方便的进行业务系统的开发；现在谈谈我们是如何构架这个平台的。

平台的构架分为引擎的封装和平台数据两部分。

 

引擎的封装

WF和应用之间的交互是通过接口和事件来实现的，在一些WF相关的例子中，为每个流程都定义了一个接口，并且在接口中又为每一种状态的每一个操作操作都定义了一个事件，一个复杂的流程就可能会定义几十个事件；这种方式仅仅是一个学习的示例，如果实际应用在项目中，那么开发和维护的工作量就太大了。

实际上我们仔细分析一个流程会发现，不同状态之间的操作都是很类似的比如同意、退回或拒绝等，而状态机流程一个时刻只能处于一种状态，所以不同状态之间完全可以共用事件，这样一个流程的接口的事件就可以压缩到只有几个。

我们再分析一下触发流程事件的参数ExternalDataEventArgs，他是包含InstanceId的，WF是根据这个InstanceId找到相应的流程，然后在触发相应的事件的；也就是说，我们在不同的流程之间可以共用一个接口；

所以我们只需定义一个接口，在该接口中为每一类操作定义一个事件，定义一个实现该接口的类，将该类实例化一次，就可以平台满足所有事件驱动的需要。

WF流程设计器支持自定义控件，引擎的封装还包括用于与平台数据进行交互的自定义控件。

比如添加审批人控件根据流程中设置的角色，将相应的人员添加到流程审批表中等等。

平台数据

企业应用是工作流应用较广的一个领域，但WF为了保证工作流引擎较广的应用范围，设计为领域无关的，没有为企业应用提供更多的支持，所以需要由平台来维护这些企业应用所必需的数据。

 

 

很多流程都是按照组织结构来逐级审批，所以我们必须在平台中维护一套用户和组织结构的数据；

不同的部门对同一个业务可能运行不同的流程，所以我们要维护流程配置的数据。

不同的流程是由不同的角色参与的，所以我们要维护角色管理的数据。

不同的角色有不同的数据访问权限，所以我们要维护菜单管理和权限管理的数据。

当前运行流程的状态和审批人都是不断的变化的，所以我们要维护流程管理的数据。

这些数据几乎是每一个企业应用都需要的，但在每个软件开发商中，这些数据结构又几乎都是不同的，WF给了软件开发商足够的空间，使其擅长的数据结构，能够和WF完美结合，满足其应用的需要。