Pixysoft.Framework.Workflow 工作流引擎开发实录

这篇随笔主要记录开发工作流引擎的实际过程。用于日后参考。

现状

之前第一代的工作流引擎都是基于ORM完成的，但是由于ORM性能太差，因此搁浅了。

 

第二代工作流引擎前几天刚刚开发完成，但是实际项目使用起来却发现有太多的问题。

1. 在分布式环境下，对持久层的调用使用了分布式的接口（insertto,updateto），因此单纯的持久层接口不够用。要么改orm、要么采用新的架构设计。

2.由于使用了ORM，但是界面都是基于datatable的，这里的转换非常麻烦。

3. 查询非常不方便，特别是表单关键字查询。

 

经过几天的思考，现在开始直接开发第四代工作流引擎（超越第三代）。

研究结果

以下的研究结果是正确的，必须遵守。

1. 工作流引擎绝对不能包含业务逻辑，例如“第三天自动提交审核”等，这种业务逻辑交给代码处理。工作流引擎只负责单据的状态处理。例如跳转到xxx状态等。

2. 工作流引擎核心目前必须围绕表单处理，而表单的c#里面直接的对应就是DataTable。

3. 工作流的流转过程全部必须有工作流引擎负责，并且有核心实体负责。

4. 工作流支持数据库表单与内存表单的处理，并且对用户而言是没有区别的。

目前有分歧的研究

1. 工作流核心实体与表单独立，核心实体处理由工作流引擎负责；表单由用户负责。当然，必须遵守几个准则：

A：表单的主键唯一确立，是链接核心实体和表单的唯一桥梁，不得任意修改。

B：核心实体的操作不暴露在外，不能被用户修改；

C：核心实体的查询允许暴露出查询结构，以DataTable形式给出。

2. 工作流暴露出来的对象只有DataTable，其他的一概不暴露出来。

 

目前存在的问题

在分布式环境下，存在特殊数据库操作接口，需要传入groupcode, 目的是减少同步数据的带宽。

 

参考文献：

http://www.javaeye.com/topic/100499 基于开源工作流引擎OSWorkflow的业务系统实例——请假审批系统