使用Windows Workflow foundation(WF)与滚动自己的工作流框架有什么好处？
据我所知,WF只提供了一个非常简单的运行时引擎,一堆类和一个用于定义工作流的模式(基于XAML).所有困难的东西,如持久性,为运行时提供主机进程,以及实现分布式工作流(跨进程)都由您自己决定.
另外,使用WF还有一个学习曲线...如果我们创建了自己的工作流框架,我们只会利用所有开发人员已有的技能(C#,XML,SQL等).
我从MS传播者那里看到了这个博客,它试图解释为什么我们应该使用WF:
为何选择Workflow？...
IMO它没有很好地说服,因为它只是说它有助于"开发人员的工作效率",同时承认开发人员可以自己动手.
任何一个聪明的人都可以提出更好的理由吗？
以下答案摘要:
我认为最有说服力的理由是使用标准化的工作流平台(如WF(而不是自己动手))将允许您利用当前和未来的工具,例如MS和第三方提供的可视化设计器.
另外,因为它是基于.NET的技术的MS堆栈的一部分,它可能会有更好的集成/迁移路径与未来的MS技术(如Azure).
最后,拥有WF经验的开发人员数量将会增加(因为这将使他们在职业生涯中受益),将其转变为基本的商品技能,如SQL或HTML,这意味着找到可以开始使用它的人变得更容易最小的加速时间.
使用WF的选择需要一些评估,我将尝试提供一个相当全面的列表,其中包含优缺点.请记住,如果您要使用WF,请不要使用WF4 +以外的任何其他内容,因为它已被重写并且经过了与其前辈相比的重大审查.
优点
成本
灵活性
耐久力
分布性
未来
在将WF与其他路径进行比较时,需要注意WF的成本.这些路径可能包括BizTalk,一个基于开源代码的框架,如Objectflow,甚至可以自己滚动.请记住,除非你需要一些非常简单的东西,否则每次都是最昂贵的方法.因此,如果您需要相当大的功能但还需要控制源代码,我建议使用开源框架.
与BizTalk这样的框架相比,WF是一个非常灵活的框架.在WF中,您可以编写自己的自定义活动,并在框架外执行您需要执行的操作 - 这确实为您提供了所需的功能.
WF包含一个非常强大的耐久性框架.它是持久的,因为工作流的状态可以持久化,工作流可以设置为空闲(以保留资源),然后稍后调用.但是,这种耐久性会进一步发展,因为它已经在主机场中设置了持久性.换句话说,工作流可以在一个主机上启动,持久化,然后在另一个主机上调用.
假设工作流通过Web服务(即WorkflowService)托管.
WF已设置为在主机场中分发.
假设工作流通过Web服务(即WorkflowService)托管.
WF是BizTalk的替换编排引擎,实际上是由构建BizTalk的人员开发的.因此,WF在Microsoft堆栈中具有光明的前景.事实上,现在微软正致力于构建单独的组件,以用组件替换BizTalk的每个功能.例如,Windows Server AppFabric(更具体地说是IIS的插件)是当今BizTalk中存在的监视服务的替代品.
为什么微软这样做？因为BizTalk不太适合云,因为它是一个大规模安装,而他们正在构建的组件可以部署到云解决方案.
缺点
灵活性
监控
WF的灵活性也可能是它的缺陷,因为有时你不需要它提供的灵活性,因此花费更多的时间来构建你本来想要包含的东西.有时你需要一个框架来做出很多假设,而且可能会违反惯例(例如MVC).但是,一般来说,我发现在将WF4框架与Ron Jacobs提供的开源扩展相结合时,情况并非如此.
对WF的监控还很年轻,这是最大的陷阱.但是,随着时间的推移,这将会非常迅速地发展,同时您可以使用自定义跟踪机制构建自己的监控工具.
资源你最好的资源是Ron Jacobs.我从来没有见过那些愿意帮助那些必须使用微软框架而不是他的开发者社区的人.相信我,他通过众多渠道提供了大量关于WF的信息,只需登陆Google并查看即可.
我可以想到的主要原因是倾向于在另一个工作流框架上使用WF:
Microsoft正在支持它作为框架的核心部分,因此它可以/将更容易集成到其他技术,如Sharepoint和Azure"云应用程序"
该工具可能会在另外几个版本中得到改进并且非常灵活,这可以提高开发人员的工作效率
京公网安备 11010802040832号 | 京ICP备19059560号-6 