WF企业应用的模式

为什么写这篇文章？

在博客园上有很多关于WF技术的文章，也有一些对WF的议论，发现大家对WF认识上有很多不清楚的地方，也有太多的误解。

有的人一遇到困难就认为WF设计的不好，其实WF这么做肯定是有它的道理的，如果你能顺着它的思路走，问题就能解决，至少我们遇到问题都是这么做的。

还有的人WF项目没有做成功，就说WF不能用。其实一个工作流项目的成功只有流程相关的那30%和WF有关，其他的70%都是和WF无关的；有多少人能保证即使不使用WF也一定成功呢？至少我见过的绝大多数项目都只能说是完成，而不能说是成功，因为开发人员对自己的要求太低，只求能用，完全不考虑优化。

我们的项目从07年10月启动，到08年4月完成，完全满足了客户复杂的需求，工作流平台随后被应用到三个新项目之中，其中两个已经上线运行。工作流平台是在第一个项目之中完成的占50%工作量，所以成本为零，但完全复用到其他项目。其他项目的开发人员不需要进行WF的培训，直接进行开发，流程开发几乎不需要编写代码，只要编写业务界面。

我们的平台不论从技术还是市场角度都是非常成功的，这一切都要感谢WF,说实话要我说出WF有什么问题，我还真提不出来，相对我的水平来说WF是完美的；所以我想替WF说几句公道话。

WF和现有工作流产品在应用范围上的区别

为什么很多人感觉WF和自己以前接触过的工作流产品大不相同，用起来比较麻烦，主要是因为现有的工作流产品和大多数我们的应用都面向的是企业应用；而WF的应用范围要广得多，从工业控制、企业应用到商业应用等等，他实现的是所有种类工作流应用的一个子集，比如工业控制中的工作流就不需要企业应用中所必须的组织结构和角色管理等，但他们流程逻辑却可能一样复杂。

WF是工作流领域的一个划时代产品，他解决了工作流应用中难度最高的引擎部分，并且可以应用于几乎所有的工作流应用领域。相对引擎而言，构建于WF之上的应用的设计开发难度大大较低，只需要较少的投入就可以实现很好的工作流产品。

为什么要用WF

开发工作流引擎的难度太高

很多人说WF用起来这么麻烦，还不如自己做呢！我想可能是因为这些人还没有遇到复杂的需求，或者对工作流引擎的难度认识还不够吧。我见过三家公司开发自己的工作流产品，每家开发的原因都各不相同，其中一家还投入了数百万，但无一例外都没有成功。而WF成功的背后是什么呢？流程设计器有微软在Visio上十几年的积累，流程文件XAML有微软在XML上十几年的积累，引擎有微软在SharePoint和BizTalk等多个版本的积累，没有这些积累，是做不了一个成功的工作流引擎的。WF出来以后就不要再想着开发自己的工作流引擎了。

WF是最好的工作流引擎

WF有很多的特性，但对我看来最重要的是下面两个特性：

细粒度的流程设计模式:WF是面向开发者的工作流引擎，它的Activity非常多，虽然每个Activity都只实现最基本的功能，但采用这些Activity设计出的流程可以非常复杂，非常灵活；现有的其他一些工作流产品，既想讨好开发者，又想讨好用户，结果两头都不靠，要么只能实现一些简单的流程，要么对于复杂的流程实现起来非常麻烦。

状态机和顺序流的分离:状态机是工作流的基础理论，只要流程中有退回操作，就涉及到状态机；我们在画逻辑图的时候可以把整个流程只画到一个图上，如果我们直接实现这个流程图，就会遇到状态的入口问题；而状态机和顺序流的分离很好的解决了状态入口的问题，，

WF企业应用的模式

上面我们说了WF仅仅实现了工作流引擎的功能，如果我们直接在上面进行应用的开发，会遇到很多困难，工作量也会非常大。所以我们必须首先实现一个工作流平台层，在这层上才可以方便的进行应用的开发。

我们将WF企业应用的模式分为三层，每层完成工作流应用的一部分功能。

 

工作流引擎层

工作流引擎层解决的是流程驱动的问题，就是下一步做什么？这一层的功能已经由WF为我们实现了，对于所有类型的流程，这一层都是相同的。

工作流平台层

工作流平台层解决的是角色驱动的问题，就是由谁来做？这一层的功能我们需要自己实现，为什么WF没有为我们实现呢？一、这不是工作流的通用需求，企业应用需要，但工业应用并不需要；二、每类企业对角色的驱动的模型是不同的，有的企业角色是一维的，有的企业角色是二维的，没法实现一个完全通用的角色驱动模型。

工作流平台层是WF应用的关键，一个设计良好的工作流平台层能够封装引擎层，使流程的开发只需绘制流程图，不需编写代码；角色的驱动也能够满足各种复杂的逻辑。

业务应用层

业务应用层解决的是用户交互的问题，就是怎么做？这一层是传统的用户界面设计，有时需要根据流程的当前节点，控制用户可以进行的操作。在这一层我们可以通过扩充ASP.NET的数据访问控件，来提高页面开发的效率。

对工作流平台层的技术要求

WF已经为我们实现了难度最高的工作流引擎层，我们只需要实现工作流平台层，就可以方便的进行业务流程的开发；工作流平台层的技术难度相对工作流引擎虽然已经大大降低，但仍然高于一般的项目开发，还需要较高的架构设计和技术能力，才能成功的实现工作流平台。

明确的需求

前面说到为什么WF没有实现一个工作流平台，是因为无法实现一个通用的企业数据模型；我们也只能根据具体项目的需求和技术实现的风险，确定工作流平台的初步架构，然后不断的根据其他项目进行扩充，从而实现多个项目的超集。所以要求我们必须非常清楚客户的需求，这样才能架构适用的工作流平台。

较高的架构设计能力

架构设计能力是实现工作流平台的关键，有两点要求，一是要能够利用WF来实现业务流程，二是要把所有流程中公共的代码提取到平台中。架构能力是设计出来的，不是学出来的，没有几年的设计经验，是很难架构一个较好的工作流平台的。

较高的技术能力

WF是一项非常复杂的技术，学习起来已经很不容易，应用就更难了，有时遇到问题，不得不查看他的源代码才能解决。WF会涉及到.NET技术的方方面面，所以没有几年的.NET技术基础，要熟练应用WF还是比较困难的。

为什么很多WF应用没有成功

很多人很看好WF，也在项目中投入了很大的人力，但项目实施效果不理想，要么不能满足用户需要，要么开发量太大，甚至于项目没有成功。下面是几种常见的情况：

没有应用状态机

只要涉及到流程的退回就应该应用状态机，我们一般把逻辑图都画在一张图上，直观上就想通过顺序流来实现它，所以有些人花了大量的精力来通过顺序流实现状态机的功能，到头来还是不能满足用户要求。

没有封装工作流引擎

WF中有很多例子，有些人依葫芦画瓢，照着例子做应用；这些例子仅仅是用来说明WF技术的，它为每个流程都定义一个接口，为每个操作定义一个事件，如果应用开发中也这么做，会极大的加重开发和维护的工作量。而实际上所有的流程可以共用一个接口，可以只为每类操作定义一个事件。

业务和平台混杂

平台的一个目标就是把业务中所有重复的代码抽取出来，业务中就不再包含平台的代码；而如果把两个混杂在一起，必定会有大量的平台代码冗余在业务代码中，增加了开发维护的工作量、架构的复杂性和系统的风险。

技术难题

WF由于技术难度较高，在开发中会遇到很多难以解决的技术问题，有些问题就像鸿沟，跨不过去就只有死在下面；有些问题就像瑕疵，解决不了就不能满足用户的需求；这些问题有时会困扰我们很多天才解决，不知道求助微软有没有帮助，我们都是自己硬啃下来的，好像没有什么捷径。

 

后面文章我们会介绍在工作流项目中流程相关的需求，及平台的架构