这篇随笔主要记录开发工作流引擎的实际过程。用于日后参考。
现状
之前第一代的工作流引擎都是基于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的业务系统实例——请假审批系统