Michael's

focus on architecture & hi-performance

使用WF来干嘛?

我们在上次的文章已经提及了WF工作流不是一个终端用户的产品。在这篇文章里我想表明一下我的观点:开发人员到底应该使用WF来干嘛?WF是.net3.0框架中的一个新技能,开发人员必须在他们创建的解决方案使用它。在与许多使用WF的客户交流后发现,重新回顾并且考虑一下WF的通常用途真的是一件非常有趣的事。这些是我所观察到的,在PDC2005中我们尚未提及。

1.创建一个进程服务器(a Process Server 或者说BPM)

到目前为止,看起来项目中WF的大多数用途是创建一个进程服务器产品。创建一个进程服务器的人已经清楚地知道了进程执行的点滴,那什么是写进程代码和所有针对该类工作所需考虑的东西之间的不同呢?WF运行时是针对进程服务器的一个通用技术,并且它代表着该类引擎的一个补充。你丝毫不用惊讶说好些个进程服务提供商已经转移到WF的麾下了。他们根本不用再来维护那些引擎代码了,他们所需要的是去关注那些高层次的特性。

但是针对大多数的.net框架开发人员来看,进程服务器是一个相对小的比例。所以真正有趣的问题是:.net框架开发人员在他们的项目中将WF用在何处?

2.冗长的商业逻辑

WF很适合用来实现长时间的商业逻辑。一些软件不需要任何商业逻辑。但是大多数的企业软件项目是需要的。它们在这方面很是需要,并且也通常会花很多时间在跟商业企业主讨论怎样的软件是需要的。我认为企业软件开发人员的工作是将商业需求“翻译” 为一行行的过程代码。当你将一个冗长的运行过程翻译到代码中时,你需要些一大堆各种各样的方法,以用作该过程的最小模块。例如响应该过程接收到的一个购物单时,可能会牵涉到从供应商取货时有些延迟。过程代码在这里不能暂停下来等待该回应(除非设计的很糟糕),你必须处理该过程中出现的各种状态,以及相对应的各种消息,一旦等待事件触发之后。WF通过在一个较高的层次建模很好的解决了该问题。你仍然必须写些代码,但是状态管理,持久化数据以及相应的消息已经被WF运行时管理起来了。

3.常变的业务逻辑或规则

WF还解决了这样一个问题:某个软件应用一次性被写成,并且随之应用许多终端客户中去。每个终端客户有他们自己正对商业逻辑应用的需要,而且在软件使用之前还有很长一段时期的个性化需要。WF提供了一个模型:在代码中构建了一系列活动,针对每个独立的客户,这些活动的代码执行顺序和活动的属性都能在WF设计器中轻易定制。软件仍然是由代码创建出来的,但是针对一个新客户的模型定制或者说一个单独客户来说,频繁的需求变化变得更加容易。

WF允许这样一个场景:在应用程序执行过程中,通过工作流模型或者一系列业务规则实现的业务逻辑能够动态更改。不需要重新部署.net程序集或者重新编译。这样就使得一个软件设计可以集中式实现业务逻辑,同时在一个普通的业务执行过程中轻易编辑变得可能。

4.需要业务逻辑或者模型内部执行机制可视化

一旦你决定将你的业务逻辑实现为一个工作流模型, 你就能够利用WF提供的各种服务。这些服务包括:ACID事务,补偿活动(compensating actions),异常管理和过程跟踪。跟踪服务可提供工作流实例的可视化需求,而且跟踪服务(Tracking Service)就像其他服务一样,不需要添加额外的代码就可添加进工作流运行时中。通常情况下,在主体软件完成之后,跟踪和日志都需要额外添加代码。

似乎就我这段时间来看,Tracking Service并不是那么好用

同时,你也能在工作流设计器中轻易看到工作流模型,你能将它打印出来,或者作为一副图片粘贴到功能设计书中去。这对于跟非开发人员解释软件的运行来说非常之有用,同时也可作为针对后来者或者代码修改人员的一份很有价值的文档说明。

原文链接: http://blogs.msdn.com/pandrew/archive/2007/02/01/what-to-use-windows-workflow-foundation-for.aspx

posted on 2007-02-06 08:48 m.s 阅读(...) 评论(...) 编辑 收藏

导航

统计信息