language-agnostic - 一切都是流？

Question

我最近从事的一些 Web 项目使用流引擎作为演示和/或(或多或少)业务层的中央抽象。回顾我的经历，老实说，我不喜欢以流程为中心的方法。甚至相反。我看到在使用流作为中心抽象的项目中会出现相同的症状。

一切都是流动的。 你不只是启动一个应用程序，不，你“进入主流程”，即使它只是为了显示一个带有巨大调度程序的菜单。我并不反对这样的流动。一些用例不断出现，需要在其他用例的各个点包含(LookupCustomer，...)，但对于以流为中心的人来说，一切都是流，即使是......不是流的东西。

碎片化。 基于流的应用程序往往有许多分散在整个代码中的逻辑( Action 、命令、准备 View 的代码片段......)。映射进出这些操作会增加开销、乏味并且会使代码膨胀。尽管遵循抽象流程很容易，但实际上弄清楚这些小(或大)代码块中发生了什么是另一回事。虽然每种应用程序风格都允许人们编写糟糕且不一致的代码，但以流为中心的应用程序使这样做变得特别容易。

配置文件。 大多数应用程序使用一些 XML 格式来声明伴随状态变化的流和 Action 。编写应用程序所使用的语言(比如 Java、C#、Ruby 等)可能比 XML 格式更加丰富和富有表现力。何苦？

流打破了封装。 如果给我一个组件，它有一定的内嵌流逻辑，那么流应该是组件的一部分，而不应该是外部抽象。换句话说:流是组件的一部分，组件是自包含的。这是一个细节。当然，它可以参数化和填充，但组件应该“正常工作”。编写 Swing、GWT 或任何胖或丰富的接口(interface)应用程序的人不会为显式流抽象而烦恼。为什么我的 Web 应用程序应该有一个？给我GMail的流程图。

(编辑)流程是程序性的。 如果你看看像 MVC 这样的“丰富”模式，其中包含事件和所有内容，相比之下，流程真的很苍白。您正在使用一种现代且富有表现力的语言来实现您的应用程序，对吧？因此，您可以比打洞卡和汇编器流行时的死板的“做这个，那个，那个，然后……”的方式做得更好。

促进以流为中心的开发的框架示例有 Struts、BTT、Spring Webflow 和 JSF。我还遇到过建立在普通 servlet 之上的国产流引擎。

这也是一篇有趣的文章: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/

您(仍然)认为 Web 应用程序(前端)的以流为中心的方法是一个好主意吗？

Answer 1

一般来说，对于一个相对简单的问题，流似乎是一种不必要的企业化方法:我们希望确保用户通过我们的应用程序采用几个特定路径之一。更有启发性和洞察力的是检查为什么我们需要这条路径发生。是不是因为...

...我们不希望他们与我们的应用程序交互，除非以严格预定义的方式？然后我们限制了应用程序的实用性，使我们的应用程序更难更改和使用。

...如果人们偏离常规，我们担心我们的应用程序处理意外输入或处理我们没有预料到的状态的能力？然后，这说明了我们对验证框架的技术选择。

...我们无法想象除了预定义的场景之外有人会使用该网站的场景吗？然后我们隐含地假设只有我们知道如何最好地使用它；我们限制了用户控制其交互的能力。

请注意，这些中的每一个都强调了应用程序开发和团队成员固有的问题，并且不是用户的错。所以我支持你的一般前提，即基于流程的方法往往存在许多问题。

主要问题是 流动不必要地增加了已经被其他机制更好地抽象的脆性。 例如，要实现“您需要在确认结帐前填写订单”之类的规则，不要制作工作流；有更好的 CustomerOrder知道何时没有允许 OrderConfirmation 所需的所有信息的模型.如果你试图跳过，你的模型和 Controller 应该注意下一个 POST 的验证失败。 .

本质上，流提取每个参与 Controller 的不同片段，并将它们收集到特定于每个流的新“流 Controller ”中。这不一定是一个坏主意，但它表明如果这种路径很容易单独定义，那么最初的 Controller 可能已经承担了太多的责任。例如，如果您之前有 OrderConfirmation , CustomerOrder , 和 OrderCheckout Controller ，而您正在考虑 Order流将所有三个链接在一起， 您可能应该考虑的是 Order而是 Controller .