为了在ASP.NET中实现这个工作流，你需要一个页面来收集人名，一个页面来收集电子邮件地址和一个页面来显示个人资料。记住，数据登录表单应该丝毫不知道之前或之后所发生的一切。对于显示页面也是如此。然而，该ASP.NET应用程序必须了解要把哪个页面显示给用户；这正是引入控制器的目的之所在。这个示例使用一个Http处理器来实现该解决方案。这个称为WorkflowController的定制的处理器负责下列任务：
·获得到工作流运行时刻的一个参考。
·获得一个到已有的或启动一个新的工作流实例的参考(这依赖于是否已启动一个工作流实例)。
·建立控制器和工作流之间的通讯。
·处理来自该工作流的事件。
·告诉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"/＞
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"/＞
三、 实现控制器逻辑
接下来，你需要以一个Http处理器来实现控制器逻辑。为了构建该控制器，所有你需要做的是创建一个称为WorkflowController处理器的类-它实现IHttp处理器接口。到目前为止，你还没有看到有关Windows WF的任何特别的东西-这是特别针对于ASP.NET的功能(请继续往下读)。
在这个WorkflowController处理器类中，名为ProcessRequest的IHttp处理器接口方法处理一个来自于该ASP.NET应用程序的Web请求。这里，你需要获得到一个静态的工作流运行时刻实例的一个参考，为该工作流建立事件处理器，并且启动工作流的执行。在启动一个工作流实例之前，你需要检查是否该请求的查询串值包含一个代表一个工作流实例ID的GUID。如果存在这个ID，你就知道已经有一个实例正在运行，这样你可以得到一个到该实例的参考并继续执行。如果不存在这个ID，你需要通过调用工作流运行时刻Start Workflow方法来创建一个新的实例并且开始执行过程。
在启动一个实例后，事件处理器将管理进出工作流的通讯。因为本文的目的不是讨论本地通讯服务，所以在此我不会详细讨论这个主题，而是分析其高级的实现技术，并再次讨论这在一个ASP.NET应用程序中是如果工作的。为了便利通讯处理，你将需要若干.NET接口--用于描述出/入该工作流和宿主的信息。你会在本文所附WorkflowClassLibrary工程源码中找到这一些。你还会找到一些实现这些接口的类以及实现工作流机制所必须的相应功能。
让我们再简单地看一下web.config文件。注意，在早些时候讨论的ASPNetThreadingService元素附近，我们使用了三个元素来描述通讯服务类:
＜add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
＜add type="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c4620ae819b5257e"/＞
这里还有一个元素，它指导工作流运行时刻库来使用SqlStatePersistenceService。这种另外的服务把一个工作流的状态持续性存储到一个在页面请求之间的SQL服务器数据库之中。你必须提前手工地创建这个数据库，但是微软提供了SQL脚本来做这件事情。你将会在C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Windows Workflow Foundation\SQL文件夹下找到它们。就象模型服务一样，你可以编程地添加这些服务，但是你也可以在配置中实现它，这将会大大降低代码的编写量并且提供灵活性-甚至在代码生产之后。而且在web.config中有一行，它添加一个HttpModule-它支持在ASP.NET中的Windows WF运行时刻库；还有一行用于设置更早些时候讨论的Http处理器控制器。如你所见，在这个配置中存在许多的东西。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
