二、 一个简单的工作流MVC实例
为了说明这一思想，我将向你展示一个简单ASP.NET应用程序和工作流。这个过度简化的工作流描述了一个进度-收集一些来自于一外部应用程序的私人信息，然后显示它。步骤如下：
1. 调用一个方法--这意味着请求一个人的名字;该工作流使用了InvokeMethod活动(见图1)。
2. 等待直到一个事件被激发--这意味着收到一个名字；在这一步中，该工作流使用了EventSink活动。
3. 使用一类似调用，从宿主获得一个电子邮件地址。
4. 等待一个事件意味着收到一个地址。
5. 在收到名字和电子邮件以后，该工作流启动一个InvokeMethod活动来发送个人资料到调用者应用程序。在一种真实世界情形，这最后一步并不很重要。更可能的是，你将调用一个Web服务来发送数据到另外的系统，或把它放进一数据库。
图1.示例工作流:这个工作流描述了隐含在示例ASP.NET应用程序中的过程
·获得到工作流运行时刻的一个参考。
·获得一个到已有的或启动一个新的工作流实例的参考(这依赖于是否已启动一个工作流实例)。
·建立控制器和工作流之间的通讯。
·处理来自该工作流的事件。
·告诉ASP.NET需要显示哪个页面，这依赖于现在正执行该工作流中的哪一层。
你已看到，这个定制的处理器实质上负责处理所有的与WWF和页面控制相关的工作--让单个的ASP.NET页面对在后台正在进行的动作保持"缄默"。Web表单需要担心的唯一的事情是执行手头特定的任务并且把必要的数据传递到控制器。
默认地，WWF以一个异步的模型工作。这意味着，当一个应用程序宿主启动一个工作流实例时，控制立即返回到该宿主，而该工作流继续在另一个线程上执行。这在一个Windows表单应用程序中可能是很有用的-其中十分期盼用户接口的连续响应性。通过使用这个异步的模型，工作流可以在后台执行而该用户可以继续操作该应用程序。然而，在一个Web应用程序中，可能不期望这种类型的行为，因为在服务器完成一个单元的工作后控制通常将只返回到用户。这正是 Windows WF的可扩展性的体现。在Windows WF中，开发者可以利用或创建"运行时刻服务"来监控甚至修改该工作流运行时刻。该示例包括：
·持续性服务-存储执行和空闲时间之间的工作流状态
·追踪服务-输出有关工作流执行的信息到某种媒体
·事务服务-帮助维持工作流执行过程中的数据完整性
另外，线程服务让开发者控制工作流实例的执行方式。如前面所讨论的，工作流运行时刻默认地将在一个独立于宿主的线程上异步地运行实例。但是由于这很可能不是ASP.NET所期望的，所以你需要交换默认工作流线程服务。幸运的是，微软已经为此提供了一种解决方案-- ASPNetThreadingService。为了实现这一变化，你或者可以手工编码方式把ASPNetThreadingService添加到工作流运行时刻服务，或在web.config文件中完成这一任务。本文中的示例应用程序使用了配置方式。在web.config(见列表1)的工作流运行时刻 /服务节中，添加类似下列的这一行：
＜add type=
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/＞
