使用Windows Workflow foundation(WF)与滚动自己的工作流框架有什么好处?
据我所知,WF只提供了一个非常简单的运行时引擎,一堆类和一个用于定义工作流的模式(基于XAML) . 所有困难的东西,如持久性,为运行时提供主机进程,以及实现分布式工作流(跨进程)都由您自己决定 .
另外,使用WF还有一个学习曲线...如果我们创建了自己的工作流框架,我们只会利用所有开发人员已有的技能(C#,XML,SQL等) .
我从MS传播者那里看到了这个博客,它试图解释为什么我们应该使用WF:
IMO它没有很好地说服,因为它只是说它有助于“开发人员的工作效率”,同时承认开发人员可以自己动手 .
这里有聪明人可以提出更好的理由吗?
SUMMARY FROM ANSWERS GIVEN BELOW:
我认为最有说服力的理由是使用标准化的工作流平台(如WF(而不是自己动手))将允许您利用当前和未来的工具,例如MS和第三方提供的可视化设计器 .
另外,因为它是基于.NET的技术的MS堆栈的一部分,它可能会有更好的集成/迁移路径与未来的MS技术(如Azure) .
最后,拥有WF经验的开发人员数量将会增加(因为这将使他们在职业生涯中受益),将其转变为基本的商品技能,如SQL或HTML,这意味着找到可以开始使用它的人变得更容易最小的加速时间 .
6 回答
简短的回答:它是 free ,它完成了工作 . 如果你可以推出一个更好的框架来管理工作流程并希望花时间在它上面,那么一定要做 . 但是考虑到 your time is worth money ,那么您愿意投入多少资金来构建更好的管理工作流程框架?我可以看到变得昂贵 .
此外,我很确定持久性(到磁盘或SQL)是开箱即用的 .
使用WF的选择需要一些评估,我将尝试提供一个相当全面的列表,其中包含优缺点 . 请记住,如果您要使用WF,请不要使用WF4以外的任何其他内容,因为它已被重写并且经过了与其前任相比的重大审查 .
优点
费用
灵活性
耐久性
可分配性
未来
成本
在将WF与其他路径进行比较时,需要注意WF的成本 . 这些路径可能包括BizTalk,一个基于开源代码的框架,如Objectflow,甚至可以自己滚动 . 请记住,除非你需要一些非常简单的东西,否则每次都是最昂贵的方法 . 因此,如果您需要相当大的功能但还需要控制源代码,我建议使用开源框架 .
灵活性
与BizTalk这样的框架相比,WF是一个非常灵活的框架 . 在WF中,您可以编写自己的自定义活动,并在框架外执行您需要执行的操作 - 这确实为您提供了所需的功能 .
耐久性
WF包含一个非常强大的耐久性框架 . 它是持久的,因为工作流的状态可以持久化,工作流可以设置为空闲(以保留资源),然后稍后调用 . But ,耐久性进一步发展,因为它已经在主机场中设置了持久性 . 换句话说,工作流可以在一个主机上启动,持久化,然后在另一个主机上调用 .
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
可分配性
WF已设置为在主机场中分发 .
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
未来
WF是BizTalk的替换编排引擎,实际上是由构建BizTalk的人员开发的 . 因此,WF在Microsoft堆栈中具有光明的前景 . 事实上,现在微软正致力于构建单独的组件,以用组件替换BizTalk的每个功能 . 例如,Windows Server AppFabric(更具体地说是IIS的插件)是当今BizTalk中存在的监视服务的替代品 .
为什么微软这样做?因为BizTalk不太适合 Cloud ,因为它是一个大规模安装,而他们正在构建的组件可以部署到 Cloud 解决方案 .
缺点
灵活性
监测
灵活性
WF 's flexibility can also be its pitfall because sometimes you don' t需要它提供的灵活性,因此花费更多时间来构建您本来想要包含的东西 . 有时你需要一个框架来做出很多假设,而且可能会违反惯例(例如MVC) . 然而,一般来说,我发现在将WF4框架与Ron Jacobs提供的开源extensions耦合时,情况并非如此 .
监测
监测WF还很年轻,这是它最大的陷阱 . 但是,随着时间的推移,这将迅速推进 very ,同时您可以使用custom tracking机制构建自己的监控工具 .
资源
您最好的资源是Ron Jacobs . 我从来没有见过那些愿意帮助开发者社区的人,他们必须使用微软's frameworks than him. Believe me, he',通过众多渠道提供大量关于WF的信息,只需登陆Google并查看即可 .
我可以想到的主要原因是倾向于在另一个工作流框架上使用WF:
Microsoft正在支持它作为框架的核心部分,因此它可以/将更容易集成到其他技术,如Sharepoint和Azure "cloud applications"
工具可能会在另外几个版本中得到改进并且非常灵活,这可以提高开发人员的工作效率
我不得不在工作中创建Workflow活动,我甚至无法告诉你答案 .
一个不太正确的原因是在工作流程图的设计时可以确定和拒绝无效的值/输入,因此基本上不存在编译时错误(假设您编写的所有样板代码都没有编译时错误) .
在Visual Studio中有一些相当不错的设计器支持,我宁愿不必为自己滚动,它是一个由其他人而不是我支持的框架,这意味着有人修复了架构错误并进行了主要测试,让我去测试只是我的工作流程我的意思是,我可以推出我自己的GDI调用版本,但我宁愿不这样做 . 我自己的序列化框架,XML解析器或.NET框架的其他一些元素也是如此 .
当涉及到它时,这些东西作为工具包提供 . 您是否选择使用工具完全取决于您正在解决的问题,工具的适用性以及您可用于实现目标的时间和资源 .
它是一项新技术或者您可以说它最新的承诺不断更新功能 .
它尊重以前的工作环境并使用它并添加那些对于长期运行的程序(大型项目)的开发非常有用的功能 .
它直接在开发人员手中产生所有这些功能,这些功能以前在后面运行,缺少内核概念和程序员之间的交互 .
是的它有点复杂,但它也提供了程序员手中的更多权力 .
在未来的未来,您可以期待更好的框架和功能 . 它是编程的未来,所以我们今天开始学习它 .