MVP 设计模式在 SharePoint Workflow 中的应用

suncool

对SharePoint Workflow进行单元测试是一个非常大的挑战。因为SharePoint Workflow 和SharePoint结合得十分紧密。众所周知，Workflow必须要寄宿到宿主应用程序中才能运行，因此，Workflow的开发者必须要定义Communication服务，使得宿主程序和Workflow之间能够交互数据。由于SharePointWorkflow的宿主固定为SharePoint，所以SharePointWorkflow能够预先做好Communication服务，并提供一系列封装好的Activity，如CreateTask,OnTaskChanged等。这样的确方便了Workflow的开发，使开发者更集中于业务逻辑。同时，SharePoint和Workflow的耦合度也大大地增加了。

目前除了购买专门针对SharePoint Workflow的单元测试软件，好像还没有更好的办法。但是，我们可以尽可能地把业务逻辑分离出来，对这部分逻辑进行单元测试。我把SharePoint Workflow开发过程中涉及的逻辑分为两部分：

1. Workflow的流转逻辑。这部分逻辑是在Visual Studio Workflow Designer里设计的，很难进行单元测试。
2.自定义的业务逻辑。这部分逻辑是指在Workflow的每一步或每一个状态中涉及的业务逻辑。如在CreateTask活动invoke的时候，我们会根据自己的逻辑去决定这个task应该分配给谁，标题是什么等等。这部分逻辑可以用我即将讲到的方法分离出来进行单元测试。

为了将自定义的业务逻辑和整个Workflow的流转分开，我们必须加入一个能够根据业务逻辑修改Workflow内容的模块。使用MVP(Model View Presenter)可以很好地达到目的。下图是使用MVP设计模式后的Workflow设计图：


                               图1. MVP Workflow High Level Design

SharePoint Workflow View: 将业务逻辑中所需要用到的数据收集起来，并暴露给Workflow Presenter.

Workflow Presenter: 负责从Workflow View中取出数据，并使用Operator提供的Method执行业务逻辑。同时，根据Operator返回的数据修改Workflow View中的数据。

Workflow Operator: 处理业务逻辑。

由此可见，只要针对Workflow Operator进行单元测试，就可测试所有的自定义业务逻辑。

接下来是一个例子。先看一下整个设计框架：



                                 图2. MVP Workflow UML

为了使Workflow1能够暴露我们所需要的数据，定义一个IWFView接口。让Workflow1实现该接口，这样，Presenter就可获得处理业务逻辑所需的数据。

定义IWFOperator，规定处理业务逻辑的操作。

SPTaskDTO是一个Data Transfer Object.它用于将Operator的执行结果传递给实际的数据对象。在这里，SPTaskDTO存有通过WFOperator.CreateTask()创建的task信息，WFPresenter负责将task信息取出，并通过IWFView.get_CreateTaskProperties().xxx= task.xxx 改变Workflow1的数据。

以下是整个应用程序的顺序活动图:



                                图3. MVP Workflow Sequence Diagram

通过MVP设计模式，可以将自定义业务逻辑完整地分离出来，从而可以进行单元测试。但是，Workflow的流转逻辑依然无法测试，希望有高手能够给出一点建议。

源代码请在附件中下载。


附件：http://down.运维网.com/data/2353779