一步一步教你实现一个工作流运行时

一步一步教你实现一个工作流运行时2011-03-31 博客园 zhuqil一

受到讲述最新版Workflow Foundation的<<WF本质论>>（WF3.0 3.5）这本书的启发,我不由自主的要为WF4.0写点等同的文章。虽然说基本工作原理根本上相同的，但是编程的模型却相差甚远（WF3.0与WF4.0 之间）。本篇文章中，我们也将看到WF4是如何作出了设计决策。

首先，让我们复习一下底层的CLR技术Continuation。Continuation能让保存恢复执行，因此，它需要包含可执行代码的指针。委托用来实现这个目的。委托有一个很大的优点，它能够双向地存储和恢复二进制文件，存储的文件仍然可以继续执行。下面代码段显示委托的双程运作。

Code Sample 1: SerializableDelegate

序列化委托提供了一个机制，能让我们暂停运行托管的线程，在另一个进程中恢复（也许在另一台计算机）。这样做有很多好处。其中最重要的是，我们移除了"亲和力"。代码不再坚守在原来的进程，甚至原来的机器。这样允许我们通过简单的添加的计算机来扩展应用程序。此外，我们现在有一些控制。例如，我们可以删除序列化的委托，而不是恢复。这样，我们是取消了执行。同样，我们可以暂停几天执行，而且不必担心内存的使用。让我们看看这个代码示例，看看如何序列化的委托，允许我们把一个程序分成几个进程。

Code Sample: Version 1

运行这个程序三次，你将会在控制台上看见“Hello world to homemade workflow foundation！” 输出。上面的代码已经为我们设计出第一个最原始的工作流应用程序。不用说，这是非常的粗糙，有很多需要改进。首先，我第一步进行可扩张性地分离（事实上，现在我们是在业务逻辑中序列化委托的）。为了实现这个，我添加一个名字为 ReadReadWrite类。将业务逻辑移动到这个类里面。这是我们的第二版：

Code Sample: Version 2

Version 2中，首先我在主程序里面放置了一个while 循环这样就不用去运行程序三次。这样就比较方便。这是非常容易让我们了解到将它们分解成不同的程序，但我们没有这样做。重构是最简单的，但是在这里有一点是值得注意的，在ReadReadWrite中使用了 NextDelegate属性，这是为了让所有的委托能分享一个统一的签名。

现在宿主程序和业务逻辑是分开的。在这一点上，我们仍然有两个宿主和业务逻辑之间的耦合。宿主需要知道是从RunStep1开始的。宿主还需要知 NextDelegate是存储延续的属性。这些耦合使得宿主不通用。我们可以消除这些耦合通过为ReadReadWrite定义一个基类，我们称它为 Activity。