我们为什么需要Windows Workflow Foundation？

今年10月的时候在北京的微软MVP大会上我做了一个关于.NET Framework 4.0中的Workflow的讲座。一场讲座下来给我明显的感觉的大部分的工程师对Windows Workflow Foundation并不是很了解，有一位MVP问我说：“你提到的这些功能，我用写代码的方式都能够实现啊？为什么我需要用工作流？”

我相信，抱有这样的一个想法的人并不是个别。从2006年底发布了.NET 3.0以来，已经两年过去了，在这个两年中WPF吸引了无数人的眼球，WCF也得到了不少用户的肯定，为什么Workflow一直无法得到广泛的推广。个人认为除了我们产品不够完善以外，主要的原因是因为Workflow实际上引入了一种新的编程方式。有别于传统的编程方式，如果你是一个刚刚接触程序设计的初学者，或者你没有经历过大型的工程开发，那么你并不是很容易理解Workflow给我们带来的好处。相反，我相信那些在一堆业务逻辑和执行代码中挣扎的朋友们会很容易体会一个好用的工作流平台能到来的编程效率提升。

说了怎么多的废话，让我们来看看什么是Workflow？
简单的说一个完整得工作流平台（Workflow Foundation）由3个部分组成： Activity（活动），Runtime（运行时）和Tooling（开发工具）。所以在我的团队里，我们将称为A.R.T——艺术。
Activity是工作流的一个工作单位，几个小的Activity能够组合在一起成为一个大的Activity，从而完成更复杂的逻辑。而一个顶层的Activity被称为工作流（Workflow），就像程序中的Main函数。
WF Runtime是Activity的执行平台，WF Runtime可以被托管在.NET的应用程序中，比如IIS。就像我们在运行.NET程序是，CLR会帮助我们管理内存，我们在WF Runtime中运行Activity时，Runtime也会帮我们关系进行诸如应用程序持久化，日志记录，数据追踪方面的工作。
大部分人可能会将Tooling理解为Visual Stuido中的工作流设计器。对，它是Tooling的一部分，但是一个好的开发工具还应该提供了调试功能，你将可以在设计器中更加直观的调试你的工作流。并且你还应该能够将Visual Studio 中支持设计器的在别的平台是使用，比如Web Page或者一个WinForm的程序上。我们将它称为Rehosting。

那我们为什么需要Workflow呢？
总来来说Workflow是为了简化协调工作而产生的，让我们来看个例子。
我们有这样一段代码，用于实现一个银行帐户的验证

首先，我们要求用户输入用户名，输入帐户之后便调用验证函数。这一切看起来都很完美似乎没Workflow什么事情。但是现在我们需要在Web建立这个程序，也许你要有页面用于输入用户名，一个页面用户输入帐号，最后在进行验证。那么你就需要建立3个函数，一个用于读取用户名，一个用于读取帐号，另一个用于验证。因为你将3个函数的逻辑分开了，那么你需要一个变量来保存当前是在输入用户名还是在输入帐号，当然你还需要添加代码来判断是否当前处于正确的状态。不可避免的，你还要添加若干代码来完成不同状态的转换。更糟糕的是你也许希望用户在关闭浏览器后重新登陆不需要再次输入用户名或帐号，那么你又将添加大段的代码来建立你的数据表，并把将这些所有数据储存在数据库。

而如果使用Workflow，你只要将把3个函数封装在不同的Activity中，并把它们依次放到Sequence Activity中。Workflow Runtime会帮你关心当前是什么状态，也会帮你管理各个状态的转换顺序。同时还能帮你完成程序的持久化，你甚至完全不需要关心数据中的表结构是什么样子的，也许你今后添加一个新的函数用于读取密码，你也不需要费尽心思去改变你的数据库结构。如果你已经把三个Activity都设计好了，你的业务设计师（也许他完全不懂得编程），也能通过设计器进行业务流程的改变。

当然，这只是一个最最小的例子。当你的业务流程变得更加的复杂，Workflow带来的便利也将更加的明显。

我们简单总结一下工作流带来的好处：

1. 简化协调工作所带来的额外工作量
工作流将业务逻辑从具体的实现中剥离出来，使你能够更专注于业务逻辑的建立，而将大量繁琐的工作交给Workflow Runtme来完成。

2. 应用程序的持久化
工作流是默认持久化运行的。你不在需要大量的代码来完成以上的工作。

3. 增强程序的透明性
因为业务逻辑和具体实现的分离，那怕是一个完全不懂编程的业务分析师也能够看懂你的程序，甚至能够自己改动你的业务逻辑。

汪宏

软件测试开发工程师