基于工作流架构的设计，最大的一个好处是实现”在产品中为用户提供流程设计器”变得比效容易。
业务需求与业务流程经常会变，如果业务流程永远不变，那就不用工作流了，直接写死的开发方式还是很快的。面对业务流程经常变化这种情况，如果不给用户提供”流程设计器”在后期维护中将是用户与程序员的一场灾难。
所以是否能为用户提供一套”流程设计器”，已评价工作流平台的一项重要指标。
以前曾看过一些结构不错的工作流开台，就是因为设计器不理想而没有使用，有的是为后期用户提供的设计器解决方案不理想，有的是为前期程序开发提供的设计器功能不足。
除了基于引擎二次开发的设计器外，自已也曾写过流程设计器。
有一次是自主开发的，象皮线的算法，层的算法…..让我觉得是在开发AutoCAD,最后在N多BUG的情况下勉强上线，用户”好”评如不断。
还有一次，也要开发一个设计器，有了上次开发UI的经历，我决定不再干自主开发”AutoCAD”,但我想到了一个CAD，那就是Visio,于是我写了一个解析Visio 2003文档的程序，用户在Visio中设计工作流，我写的程序解析Visio文件后生成工作流模板。这次的方案在内部测试时非常成功，可是在实例应用中，用户在Visio中充份发挥了其设计天份，将我的解析器一次次干掉。
还有一次，使用的是向导方式，说实话这是最成功的一次，可是单位与用户都觉得不是拖拉拽模式，太土
设计器是用来设计修改工作流模板的，在从多工作流平台里，工作流模板一般是一组存在数据库中的记录或一个XML配置文件。这也就为我上面所说的自己开发设计器提供了可能。
WWF的工作流模板比效特别，是一个类，不过好在是一个可用XML描绘的类，或者可以看作一个对流程数据的ORM.结构比效不错，但有一个至命的问题(后面的文章我会提，在项目中集成VBA开发包也可部分解决)，不知在NET4.0中是否能解决
现在又到了WWF的世界，我的“在产品中为用户提供流程设计器”的恶梦是否会在这里终结吗…..
其实这个恶梦永远不会终结，因为教用户使用设计器就是一个最大的恶梦
这方面的文章将放入WWF_designer 专栏,近期将贴上