WF 的实际应用

WF的实际应用：Windows Workflow Foundation应用程序最佳实践

本文使用以下技术：

https://www.360docs.net/doc/e212942256.html, Framework3.5、Windows Workflow Foundation和Visual Studio2008

目录

工作流编程模型

带副作用的编程

服务，服务，服务

分段执行

单元测试仍是您的好帮手

运行时内的运行时

两极式思维不可取

即插即用

域建模和程序设计

其他建议

Windows Workflow Foundation(WF)是https://www.360docs.net/doc/e212942256.html, Framework3.0的一部分，自其发布以来，我花费了大量时间研究此技术，使用它实现系统并将相关经验传授给其他人。通过这些经验，我大致总结出一些最佳实践（也有称不上是最佳的），在现实生活中使用WF实现软件解决方案。

我曾经遇到过WF出现貌似识别危机的问题。与我交谈的许多开发人员，都在一定程度上了解WF是怎么回事：条件逻辑、流控制、原子操作等等。

“是的，我想我是了解的。您将一些形状拖动到设计图面上。这些形状代表在某种“流程图”序列中执行的操作。这种方法真是太巧妙了！”之后可能会略表异议“但是，我能用它来做什么呢？”或“但是，我在C#或Visual Basic中就已经可以执行这样的操作了！”

从理论上说，这些异议都是合理的。虽然从表面上看，WF就是在Visual Studio中的拖放设计器体验，其功能与其他程序的功能看起来也并无大异，但这种外表之下确实存在优点。

要了解WF的价值所在，知道一些历史背景将会很有帮助。自.NET Framework问世之初，它的主要目标之一就是提高构建Wi ndows软件程序的抽象级别。过去，Windows编程人员需要掌握COM、HRESULT、智能指针、MTA、消息泵、thunk层等很多非特定于域的细了内容，任务非常艰巨。

幸好，.NET Framework的出现已成功解放了编程人员，使他们不必再掌握其中大部分细节内容了。实际上，我们大部分开发人员认为，打开Visual Studio并立即开始编写直接映射到手头问题的代码再正常不过了。令人高兴的是，.NET在运行时会考虑以下问题：内存管理、实施安全策略、代码依赖关系运行时解析和大量的其他详细问题。所以，如今的许多开发人员比以往更有效率。

在通往更高的编程抽象级别的历程中，WF代表逻辑的下一个步骤。WF程序在特殊运行时环境中执行，其本身在.NET CLR上运行。WF运行时环境对开发人员编写在该环境中运行的程序施加了一些限制。但是反过来，WF提供了一组功能强大的、灵活且可扩展的运行时服务，例如支持长时间运行代码，代码执行操作可以持续几天甚至几个月；支持暂停/恢复/取消运行程序；支持审核和跟踪程序执行，甚至支持修改正在运行的程序逻辑！

WF的核心是其声明性编程模型。也就是说，通常，在WF中您可以在Visual Studio中拖放WF设计器，来描述您希望程序完成的任务。但是，您不能精确指定如何完成此任务，反而是WF运行时使用您的程序说明（即控制流和活动的层次图）作为执行计划逻辑的蓝图。

工作流编程模型

在Visual Studio中使用工作流设计器5分钟，您就会明白WF是一种组件技术。WF中的一个组件就是一个活动。更具体地讲，WF中的组件是Activity基类的任何子类。

活动是WF中的操作组合和执行单位。某些活动（这些活动对CompositeActivity进行子分类，而CompositeActivity本身对Act ivity进行子分类）具有子活动，作为父活动的执行序列的一部分执行。实际上，WF中的工作流就是这些活动的流程图，从单个根活动开始，然后向任意深度和复杂性扩展。图形中每个活动的原始逻辑，结合此逻辑控制的数据，最终确定活动执行顺序和整体工作流行为。我喜欢把WF活动看成是Lego块。您可以将不同颜色、大小和功能的单个Lego块（单独每一块的价值很小）合并，构建一个大的整体，其价值超过所有块价值的总和。与此相似，在WF中，您将执行离散函数的原子活动合并，以创建高阶逻辑集，然后再将这些逻辑集合并来实现大型业务流程等等。

通常，组件编程（尤其是WF）常见的一种模式更青睐于组合，而不是继承，这样才可以重复使用。长时间使用WF构建日益复杂的工作流，您将会更加认为您正在从小型、自治活动组合程序，而不是创建基于使用C#或Visual Basic编写的复杂系统的深类层次。

您仍能够在WF中将类继承用作重复使用技术。从SendEmailActivity派生以创建对象，假设创建的是SendEncryptedEmailActi vity，没有任何问题。在这种情况下，您正在更改执行的操作的基本特征，在此继承技术自然就派上用场。但是，如果需要根据条件仅在特定环境下发送电子邮件，或者在发送电子邮件前后执行其他任务，则最好选择使SendEmailActivity成为另一个CompositeActivity 子类（例如，SequenceActivity或IfElseActivity）的子项，然后在SendEmailActivity外定义其他逻辑。

图1显示了封装有条件的电子邮件操作的复合活动。在该图中，SendEmailActivity仅负责发送电子邮件，从而提高了它在其他工作流中重复使用的机会。它还允许您重复使用WF（支持条件分支和顺序活动执行）中现有的结构，而不需要从头开始编写新代码。

图1具有条件逻辑的自定义组合活动

带副作用的编程

在编程中，对副作用的定义为：因执行程序的某一部分导致的对共享状态的明显更改。副作用的示例包括更改对象属性的值，或更改数据库表中的一个或多个值等等。在软件中完成实际工作一直用到副作用。

在进行纯函数式编程时，避免共享状态，并且主要通过方法返回值来进行数据流动和操作，与这种编程方法相比，工作流中一切有趣的内容会都带来某种副作用。在工作流程序中，没有返回值等内容，但是，您可以比较执行前和执行后状态来查看更改。您通过使各个活动内外组合，而不是通过调用方法来指示控制流。在设计活动类（作为属性）时活动输入和输出是隐式的，而不是通过方法参数或返回值显式定义的。数据从一个活动到另一个活动的流动，是通过内置支持活动数据绑定完成的。通过与您的自定义WF活动逻辑中的配置的服务进行交互，您也可以选择处理共享状态。

WF活动的基本执行顺序是初始化活动状态、执行活动、检查合成的活动状态是否发生更改，然后对所有其他活动重复上述操作。那么，这恰恰就是活动执行的副作用（“PurchaseOrderTotal属性的新值是什么？”或“哪些数据库值刚刚进行了更改？”），告知您刚刚发生的情况以及接下来要发生的情况。您可能会使用不适用于其他下游活动的方法使活动处理状态（然而，请注意，此处的风险不会高于C#之类的任何命令式语言中所固有的风险），但不必担心数据复制出现问题。

服务，服务，服务

作为一种具有一般目的的编程环境，WF旨在与外部子系统和代码集成。完成此任务的最直接的方法是，创建自定义工作流活动，来调用数据库、Web服务或第三方库。在WF术语中，这样的外部系统称为服务。

WF服务的原理很简单：您的工作流中的活动所需的、但又不包含在活动定义中的任何库或功能元素，在WF运行时注册为服务：//create an instance of your service type...

LoggingService logSvc=new LoggingService();

//register it with the WorkflowRuntime instance...

workflowRuntime.CreateWorkflow(typeof(Workflow1));

在执行期间，活动可要求通过ActivityExecutionContext（活动从不与主机运行时直接交互）访问所需的服务，并使用配置的服务执行任务，同时使WF运行时和主机管理服务生存期：

protected override ActivityExecutionStatus Execute(

ActivityExecutionContext aec){

//ActivityExecutionContext provides access to services...

LoggingService logSvc=aec.GetService();

Debug.Assert(logSvc!=null);

logSvc.LogEvent(EvtType,Message);

典型服务示例包括记录组件、数据访问层和外部子系统的代理，当然还可能有更多的其他服务。

WF服务模型的强大功能源于其简单性。简单地说，即任何.NET对象都可以配置为服务。请注意：某些其他行为，如服务生存期管理，适用于专为WorkflowRuntimeService划分子类的服务。此外，我经常发现通过接口（而不是通过实际键入）公开服务很有用；这将使区分独立于依赖服务的活动的服务实现更加轻松。

因此，此时关键的最佳实践就是从完成此任务所需的构成片段减少自定义WF活动的核心逻辑。此外，您应该重构具有状态的服务逻辑，在工作流中多个活动之间共享（例如，记录）；在执行期间将引用沿活动图形向下传递给记录组件是件繁琐的事情。这对于在执行周期期间的某个点进行序列化的工作流来说将更加复杂。

接下来，我将介绍其他一些与服务有关的建议。Windows WF附带一个基础结构（称为本地服务），用于调用活动中的.NET类实例并处理活动内部的.NET事件。您可以通过CallExternalMethod和HandleExternalEvent活动与这些本地服务进行交互。他们实质上是位于基本WF服务基础结构顶部的附加层，并可以提供与更适合WF主机环境（例如SharePoint）的声明性形式的原始服务相同的好处。但是，对于更多通用的主机，例如Windows Presentation Foundation(WPF)或https://www.360docs.net/doc/e212942256.html,，此附加层使用起来可能比同等的原始服务配置更加繁琐。请记住，在使用本地服务构建解决方案之前预先考虑承载要求。

此处使用的关键原则是利用WF服务模型的功能和灵活性设计分解合理的、可重复使用的工作流活动。

分段执行

使WF非常适合通用编程任务的一个功能是它支持异步、无阻塞任务。现代以Web服务和以数据库为中心的应用程序的本质是适应异步调用，即发出服务请求后，释放出与该请求调用关联的本地资源以处理其他任务。稍后，完成调度的任务后，执行可在其退出的位置继续进行。https://www.360docs.net/doc/e212942256.html,异步页面是此项技术的一个示例。

当WF运行时首次执行活动时，即调用其Execute方法。活动执行Execute中的所有任务后，Execute将返回ActivityExecutio https://www.360docs.net/doc/e212942256.html,pleted。当Execute执行了尽可能多的任务，正在等待某些外部促进因素（例如，对Web服务或数据库调用或发送到特定地址的电子邮件的响应）以继续执行操作时，返回ActivityExecutionStatus.Executing。

图2显示了活动的Execute方法，用于查询外部服务以获取给定客户ID的信用评分。由于信用评分可能需要花费几分钟甚至几小时的时间才能完成，因此工作流将异步调用服务，然后闲置等待结果。在闲置之前，此活动将注册委托以在促进因素到来时由运行时调用。此委托称为延续（字面意思是“指向程序的其余部分的指针”），允许活动创建或定义继续活动进程所需的任何逻辑。单一工作流的生存期可能由几个这样的闲置-继续状态转换构成。

图2Execute方法

protected override ActivityExecutionStatus Execute(

ActivityExecutionContext aec){

if(string.IsNullOrEmpty(SSN)){

throw new InvalidOperationException("SSN property value is invalid.");

ICreditScoring creditSvc=aec.GetService();

Debug.Assert(creditSvc!=null);

WorkflowQueuingService queueSvc=aec.GetService();

Debug.Assert(queueSvc!=null);

Guid queueName=Guid.NewGuid();

WorkflowQueue queue=queueSvc.CreateWorkflowQueue(queueName,false);

https://www.360docs.net/doc/e212942256.html,puteScoreAsync(SSN,queueName);

与工作流实例相关联的工作流队列上的项目（任何.NET对象）到达后，运行时会接收到外部促进因素的通知，来唤醒闲置工作流。当异步调用Web服务时，等待响应的代码将获取对队列的引用，并将相关数据（推测是最终从Web服务接收的任何内容）推入队列。运行时监视队列并调用注册的委托；委托逻辑可获取加入队列的项目并执行任何必要的处理。

此方法的强大功能源于工作流在空闲期间执行的操作。从其Execute方法返回ActivityExecutionStatus.Executing的活动很显然在某段时期内没有执行任何任务（因此，被视为空闲状态）。可能需要花费几秒钟、几个小时、几天甚至几个月的时间来等待某些外部促进因素。在这段时间，工作流不需要继续保留在内存中消耗计算机资源，而是释放这些资源使其更充分得到利用，因此WF运行时支持自动从内存卸载这样的工作流，然后将它们序列化到持久存储，以使用SqlWorkflowPersistenceService等持久服务。当外部促进因素到达时，WF运行时将重新加载工作流并继续正常执行。

单元测试仍是您的好帮手

单元测试始终与致力于WF的编程人员的生活息息相关。实际上，WF的显式组合特性本身适用于编写一组全面的测试，以测试您的解决方案的各个片段是否与其他片段脱离。我将在此处为您提供一些较高级别的信息，但是您一定要访问2008年11月这一期的《M SDN杂志》中由Matt Milner撰写的Foundations专栏文章（“单元测试工作流和活动”），以深入了解单元测试工作流。

对于使用WF有一种常见误解，即您只能执行整个工作流（也就是说，进行子分类后的SequentialWorkflowActivity实例）。实际上，您可以将任意活动实例作为独立的工作流执行，以便轻松地使用通用活动测试工具执行活动，并验证活动是孤立存在的还是更大的整体中的小子集。图3展示的就是这样的测试工具。

图3通用工作流测试工具

protected DictionaryExecuteActivity(

params object[]inputs){

Dictionaryoutputs=null;

Exception ex=null;

using(WorkflowRuntime workflowRuntime=new WorkflowRuntime()){

AutoResetEvent waitHandle=new AutoResetEvent(false);

delegate(object sender,WorkflowCompletedEventArgs e){

outputs=e.OutputParameters;

delegate(object sender,WorkflowTerminatedEventArgs e){

ex=e.Exception;

foreach(object svc in services){

workflowRuntime.AddService(svc);

Dictionaryparms=new Dictionary();

for(int i=0;i

Debug.Assert(inputs[i]is string);

parms.Add((string)inputs[i],inputs[i+1]);

WorkflowInstance instance=

workflowRuntime.CreateWorkflow(activityType,parms);

if(ex!=null){

Assert.True(false,ex.Message);

“data in/execute code/make assertions against data”（输入数据/执行代码/根据数据得出结论）这种面向状态的基础测试模式，非常适合于使用通用测试工具对WF进行测试。WF运行时支持自动填充根活动属性值（使用以属性名称作为键的通用Dictionary）。它还允许您在活动执行完成后，检查根活动属性值。即使您的活动最终将嵌入工作流层次结构内部几个层级，并且活动依靠数据绑定初始化其属性值，您也可以测试此活动是否孤立存在并模拟该活动的全部预期的错误情形。

WF也非常适合使用更高级的单元测试技术进行测试，如对象模拟，该技术着重于将测试的代码从其依赖关系中隔离，并验证对这些依赖关系的期望值（例如，“执行此测试的代码时，我预期为此依赖项调用Foo()方法的次数恰为3次”）。下面是一个示例：

//mock the IBanking interface...

var bankingMock=new Mock();

//specify that you expect AddCustomer to

//be called with the customer instance...

bankingMock.Expect(bank=>bank.AddCustomer(customer));

//execute WF harness,configuring the mock as a service...

ExecuteActivity(typeof(AddCustomerActivity),

new List