我最近工作的一些Web项目,使用流引擎作为演示和/或(或多或少)业务层的中心抽象.反思我的经历,我可以诚实地说,我不是以流动为中心的方法的粉丝.相反甚至.我看到在使用flow作为集中抽象的项目中弹出相同的症状.
一切都是流动的.你不只是启动一个应用程序,不,你"进入主流程",即使只是为了显示一个带有巨大调度程序的菜单.我并不反对这样的流动.一些用例不断出现在各处,需要包含在其他用例中的各个点(LookupCustomer,...),但对于以流为中心的人来说,一切都是流,甚至是不流动的东西.
碎片.基于流的应用程序往往具有分散在整个代码中的许多逻辑(动作,命令,代码片段以准备视图......).映射进出这些操作会增加开销,繁琐且代码膨胀.虽然很容易遵循抽象流程,但实际上弄清楚这些小块(或大块)代码中发生的事情是另一回事.虽然每种应用程序样式都允许人们编写错误且不一致的代码,但以流为中心的应用程序使得这样做变得特别容易.
配置文件.大多数应用程序使用某种XML格式来声明伴随状态更改的流和操作.编写应用程序的语言(比如Java,C#,Ruby,...)可能比XML格式更加丰富和富有表现力.何必？
流动打破了封装.如果你给我一个具有某种嵌入式流逻辑的组件,那么流应该是组件的一部分,而不应该是外部抽象.换句话说:流程是组件的一部分,组件是独立的.这是一个细节.当然,它可以参数化和填充,但一个组件应该"正常工作".编写Swing,GWT或任何胖或丰富的接口应用程序的人不会为显式流抽象而烦恼.为什么我的Web应用程序应该有一个？给我GMail的流程图.
(编辑)流程是程序性的.如果你看看像活动和所有事情的MVC这样的"丰富"模式,相比之下,流程真的很苍白.您正在使用现代和富有表现力的语言来实现您的应用程序,对吧？因此,你可以做得比刚出现的"做这个,然后是那个,那个,......"的方式做得更好,就像穿孔卡和汇编器时尚一样.
促进以流为中心的开发的框架示例包括Struts,BTT,Spring Webflow和JSF.我还遇到了在普通servlet之上构建的本土流引擎.
这也是一篇有趣的文章:http://chillenious.wordpress.com/2006/07/16/on-page-navigation/
您(仍然)认为网络应用程序(前端)的以流为中心的方法是个好主意吗？
一般来说,流程似乎是一个不必要的企业方法,应该是一个相对简单的问题:我们希望确保用户通过我们的应用程序采用几种特定路径之一.更有启发性和洞察力的是检查我们为什么需要这条路径发生.是因为......
...我们不希望它们与我们的应用程序交互,除非是以严格预定义的方式？然后我们限制了我们的应用程序的实用程序,并且我们使应用程序更难以更改和使用.
...我们担心我们的应用程序处理意外输入的能力或处理我们没有预料到的状态,如果人们偏离了人迹罕至的路径？然后,这说明了我们对验证框架的技术选择.
...我们无法想象除了某些人会使用该网站的预定义场景之外的场景？然后我们隐含地假设只有我们知道如何最好地使用它; 我们限制用户控制其交互的能力.
请注意这些内容中的每一个都强调了应用程序开发和团队成员固有的问题,以及不是用户错误的问题.因此,我支持您的一般前提,即基于流的方法往往存在许多问题.
主要问题是流量不必要地增加脆性,而这种脆性已经被其他机制更好地抽象化了.例如,要实现"您需要在确认结帐前填写订单"之类的规则,请不要制作工作流程; 有一个更好的CustomerOrder模型,知道什么时候它没有所需的所有信息允许OrderConfirmation.如果您尝试跳过,您的模型和控制器应该负责下一次验证失败POST.
从本质上讲,流程会提取每个参与控制器的不同片段,并将它们收集到一个特定于每个流程的新"流控制器"中.这不一定是个坏主意,但它表明,如果这种路径很容易单独定义,那么原始控制器可能已经承担了太多的责任.例如,如果您之前有过OrderConfirmation,CustomerOrder和OrderCheckout控制器,并且您正在考虑Order将所有三个连接在一起的流程,那么您应该考虑的是Order控制器.