Microsoft在.net 4.0中队Workflow Foundation做了较大的调整，改变了自.net 3.0以来的工作流思路，将WF提升为一种开发方式。尤其是和WCF做了无缝的集成，可以直接将一个工作流暴露为WCF应用。在Windows Server AppFabric出来之后，我们可以可以在IIS中直接对WF WCF Application进行追踪及持久化等诸多管理。其实在使用了WF以及WF WCF Application之后，虽然感叹.net技术发展的迅速以及其资源、技术整合能力的强大之外，但也有不少失望，或许谈不上失望，确切的说，应该是没有达到使用前，或者如微软官方介绍所带来的预期。
首先，微软将WF作为一种新的开发方式的努力，其实很难普及，或许长远来看，这种基于可视化逻辑的开发会进一步发展，但是在WF 4.0中，一段非常简单的逻辑实现起来可能都非常费劲，vs2010加载项目的资源占用很高，workflow编辑界面浏览的速度很慢。对于一些业务操作方法，我在想是直接在workflow中Invoke呢，还是实现成一个Activity呢？我实现过一个稍微复杂一点的工作流，结果维护起来非常麻烦，改变一个参数，都会造成对工作流的彻底调整。而是用传统的方法---直接写代码，可能不会超过100行代码就可以实现，可是使用工作流的代价反而更高。工作流采用声明式的方式，可以分解工作，业务人员可以画好工作流，而开发人员负责流程的具体实现。我们没有这么细的分工，确实无从感受到这种分工带来的好处。除非微软以后把整个.net framework实现成WF版，所有的类都转成activity。
或许有人会说对于WF4.0，虽然它可以支持在任何层次的开发，但是它的优势在于与IIS,AppFabric的整合，在于可扩展部署架构的实现。确实，AppFabric可以将WF WCF Application持久化到数据库中（Persistence），而且可以支持对WF WCF Application的跟踪（Tracing）和监控（Monitoring）。当然最重要的还是持久化，所有的请求都可以持久化到数据库中，可以由多台应用服务器来加载执行，这对于长时间执行的任务来说确实是个不错的方案，但是对于要求快速响应的服务来说，似乎有点挑战，不过可以及时响应的则直接执行返回，不能及时响应的则持久化到数据库，分配其他服务器来响应。这听起来确实不错，不过对于一般企业来说，其提供的服务器有限，未必能够“享用”到工作流架构带来的优势，确要承受工作流不是很好的性能。关于工作流的性能，微软只提供了wf4.0和wf3.5等之间的比较，却没有提供wf与其他方式之间的性能比较。
其实AppFabric也还有待进一步提升。例如异常处理，对于外部的调用，如果出现未知异常，那么究竟由AppFabric来捕捉呢，还是内部做出处理呢？如果内部不做处理，那么可以充分利用AppFabric的Monitoring，但是如此一来，异常信息(StackTrace)极容易落入客户之“手”。
记得同事问我，为何一定要使用WF呢？我说不一定，WF没有非用不可的优势。我个人的感觉是，不必要盲从微软的宣传而在细小的业务逻辑实现部分使用WF，能直接编码实现就直接编码。对于具有一定业务规模的服务来说，可以尝试WF+IIS+AppFabric的优势，如果不必要使用WF而使用了WF，只会增加工作量和维护难度，而且损失了性能。