何时使用Windows Workflow Foundation？

有些东西更容易实现(代码),但有些东西通过WF更容易实现.看起来WF可用于创建(几乎)任何类型的算法.所以(理论上)我可以在WF中完成我的所有逻辑,但对所有项目来说这可能是个坏主意.

在什么情况下使用WF是一个好主意,何时会使事情变得更难？WF与手工编码的利弊/成本是什么？

1> Panos..：

---

只有在满足以下任何条件时,您才需要WF:

你有一个长期运行的过程.

您有一个经常更改的流程.

您需要一个流程的可视化模型.

有关更多详细信息,请参阅Paul Andrew的帖子:Windows Workflow Foundation的用途是什么？

请不要将WF与任何形式的可视化编程混淆或联系起来.这是错误的,可能导致非常糟糕的架构/设计决策.

---

我无法抗拒:只有在满足以下任何条件时才可能需要WF:false.

---

@ivorykoder"进程"(真正的*工作流程*)可以在托管它的服务器重新启动后继续存在.

---

长时间运行过程的测量单位是什么？

2> Ronnie Overb..：

---

决不.你可能会后悔的:

陡峭的学习曲线

很难调试

很难维护

不能提供足够的功率,灵活性或生产力增益来证明其使用的合理性

可以并且会破坏无法恢复的应用程序状态

我唯一能想到使用WF的原因是我想为最终用户托管设计师,甚至可能不是.

相信我,没有什么能像你编写的代码一样直接,强大或灵活,完全按照你的需要去做.远离WF.

当然,这只是我的意见,但我认为这是一个非常好的.:)

---

-1我尊重你对此的看法,但会对专业的原因有所了解.我无法看到这种答案如何帮助任何人

---

短语:_"没有提供足够的力量,灵活性或生产力来证明其使用的合理性"_对我来说足够了.谢谢你.

---

我在WF4生气的那天写了这个答案.我将用我遇到的问题更新我的答案.

---

我们从一位顾问那里继承了一半完成的项目,该顾问以WF为骨干.它容易出错,无法重新启动的工作流程损坏,古老的版本控制系统需要完全复制工作流程以进行任何微小的更改,可怕的生成代码以及如此精细的代码,您必须使用小孩手套处理它.经过6个月的黄色死亡之后,我们废弃了整个WF并使用了xml.我们做出的最佳决定.

3> craigb..：

---

WF生成的代码很讨厌.WF带来的价值在于系统的可视化表示,虽然我还没有看到任何东西(现在有6-7个项目正在与我参与的WF一起工作),我不喜欢更简单的手工编码项目.

---

阿门.看我的回答.

4> Mas..：

---

通常,如果您不需要持久性和跟踪功能(在我看来是主要功能),则不应使用Workflow Foundation.

以下是根据我的经验收集的Workflow Foundation的优缺点:

好处

持久性:如果你将有许多长时间运行的进程(想想几天,几周,几个月),那么Workflows对此非常有用.空闲工作流实例将持久保存到数据库,因此不会占用内存.

跟踪:WF提供跟踪工作流中执行的每个活动的机制

*可视设计师:我把它作为*,因为我认为这只是用于营销目的.作为开发人员,我更喜欢编写代码而不是直观地将事物拼凑在一起.当你有一个非开发人员制作工作流程时,你经常会遇到一个令人困惑的混乱局面.

缺点

编程模型:你的编程功能非常有限.想想你在C#中拥有的所有强大功能,然后忘记它们.C#中简单的一行或两行语句成为一个相当大的块活动.这尤其是输入验证的痛苦.话虽如此,如果你真的小心谨慎地只保留工作流中的高级逻辑,以及C#中的其他所有逻辑,那么它可能不是问题.

性能:工作流占用大量内存.如果您要在服务器上部署大量工作流,请确保您拥有大量内存.另请注意,工作流程比普通C#代码慢得多.

陡峭的学习曲线,难以调试:如上所述.你将花费大量时间来弄清楚如何让事情发挥作用,并找出最佳的做事方式.

工作流版本不兼容:如果使用持久性部署工作流,并且需要对工作流进行更新,则旧的工作流实例将不再兼容.据说这是在.NET 4.5中修复的.

您必须使用VB表达式(.NET 4.5允许C#表达式).

不灵活:如果您需要Workflow Foundation未提供的某些特殊功能或特定功能,请为很多痛苦做好准备.在某些情况下,甚至可能无法实现.谁知道,直到你尝试？这里有很多风险.

没有接口的WCF XAML服务:通常使用WCF服务,您可以针对接口进行开发.使用WCF XAML服务,您无法确保WCF XAML服务已在接口中实现了所有内容.您甚至不需要定义接口.(我所知道的...)

---

你的大多数缺点都是不正确的,也许你对WF不够熟悉.WF非常灵活.它允许您编写可在任何方案中重用的自定义活动(代码活动).由您来编写可重用的活动.想象一下,您将能够向业务顾问提供GUI(带有工作流设计器主机的WPF应用程序)以及一组活动工具.现在,他们可以根据需要更改和重新安排业务逻辑,他们不需要开发人员甚至编译新的应用程序.

---

现在想象一下,商业顾问必须使用您的自托管设计师,但没有Intellisense!您可以自己滚动,也可以使用Visual Studio.我还认为,商业顾问甚至难以理解补偿,取消,异常处理等一些概念.此外,任何远程复杂事件的逻辑都会导致巨大的工作流程变得无法维护(哦,你需要大量的ram来编辑这样的工作流程).您是对的,精心设计的自定义活动确实提供了相当大的灵活性.

5> Tegan Mulhol..：

---

我发现使用工作流基础的主要原因是它在跟踪和持久性方面带来了多少开箱即用.启动和运行持久性服务非常容易,这可以在多个实例和主机之间实现可靠性和负载分配.

另一方面,就像表单应用程序一样,工作流设计师推动你的代码模式也很糟糕.但是,您可以通过在工作流中不编写代码并将所有工作委派给其他类来避免问题,这些类可以比工作流更优雅地进行组织和单元测试.然后,您可以获得设计师的酷炫视觉效果,而不会背后留下意大利面条代码.

6> Rob..：

---

就个人而言,我不会在WF上出售.它的用处并不像其他新的MS技术那样明显,比如WPF或WCF.

我认为WF将来会在商业应用程序中大量使用,但我没有计划使用它,因为它似乎不适合我的项目工作.

7> 小智..：

---

我目前正在工作的公司建立了一个Windows Workflow Foundation(WF)以及他们选择使用它的原因是因为规则经常会发生变化,这会迫使他们重新编译各种dll等等他们的解决方案是将规则放在数据库中并从那里调用它们.这样他们就可以改变规则而不必重新编译和重新分配dll等.

---

太糟糕的常规Web服务和应用程序没有.config文件,无法读取数据库,也无法读取XML或包含规则的本地文件,无需重新编译.等一下...

8> 小智..：

---

Windows Workflows引诱非编码IT经理,BA等,就像其堂兄BizTalk一样,但在实践中,单元测试,调试和代码覆盖只是众多陷阱中的三个.你可以克服其中的一些,但你必须投入大量资金才能实现这一目标,而使用简单的代码,你就可以获得.如果你真的有一个长期运行的要求,那么你可能需要更复杂的东西.我听说过关于能够在不重新编译dll的情况下将新的xaml文件投入生产的论点,但老实说,Workflows消耗的时间可以更好地用于改进你的持续集成到编译部署不成问题的程度.