WF不是工作流

今天没喝酒，今天心情很正常，
所以这篇文章不是胡说八道，也不是心情不好的发泻。
是很久以前就想写的而没有写的!

WF不是工作流，或者说不是实现业务的工作流平台，这个观点我在WWF b1时就这样认为的。

我在[天很蓝,应该不会下雨]、[又一个轮回开始了]、[再谈工作流-关于MS 的WF与SharePoint3.0工作流]几篇短文中有这种观点的隐含表述，在[5年了能回头再看BackOffice]中, 也有很这种观点的隐含表述。

今天，我将该观点的表确表述出来.

//先跑一下题
/*
当软件开发从面向过程转向面向对象以后，早期出现了OO、OOP、OOAD、MVC 、ORM、IOC。这些概念或模式最终目的就是为了实现重用、封装、不观心细节的调用、数据与控制相分离、数据与展现想分离、内存对象持久化、对象实例化的外部控制。
随着发展，又出现了SOA、AOP。
如果说对象是分子，
SOA关心的是由N多分子所组成的真实物体的特性，以及如何将这些物体组成一个更复杂的复合物体(如:水H2O,二氧化炭CO2)
那AOP则是以关心如何修改组成分子的原子核结构.

这些模式的应用将面向OOAD推向了顶锋，但在很多人都在谈论如何解藕时，有一些问题也暴露出来，

给你心脏、肝脏、等所有的人体器观，你能组装出一个有思想的活人吗？
*/
//跑题结束

面向对象的一个特点就是在设计对象时不考虑该对象与其他对象的关系，就算有时考虑，也只是考虑静态关系，没有考虑动态关系。
在这种情况下，我们编写完基本对象后，还要写一组将基本对象组装在一起的类，通常叫做构造类。还要写一组系统运行时管理、协调对象装态的类，通常叫做流程控制类。

很多时候让我们头疼的就是[流程控制类]

WF为我们提供了一个在设计时与运行时修改控制流程的方案。

也就是说WF是一个软件开发的架构，而不是传统意义上的业务工作流平台。

举个例子，一个配制向导模块，每个窗体完成一项具体的配制操作，向导不是单线流程，有很多分支与回退，我们如果在每个窗体的下一步按钮中写上判断下一步该打开那个窗体的按钮，这样无疑要添加得多状态控件代码与逻辑判断代码。
如果我们将这些独立的窗体放入一个流程控制体系统中，那么我们就可以很专注的做两件事，设计控制实现，设计业务流程。
这个架构就是WF

当然，WF也可以开发业务工作流平台，如BizTalk、SharePoint、Project

最后说几句：
1.WF不是业务工作流平台，是一个面向流程设计的架构
2.WF是程序员的平台，不是业务用户的直接平台
3.可以用WF设计业务工作流，
建议方式是(使用WF程设计的架构->开发一个独立的业务作流平台->基于该业务作流平台开发用户应用)
4.设计业务工作流可以不用WF,其他的实用程序也可以使用WF,如开发红擎、大富翁(^_^)

NET3.0为我们提供了三个架构，一个是通信架构、一个是UI架构、一个是面向流程的程序开发架构

//本文还没结束,有后续