欢迎大家探讨对Spring Web Flow的评价

   个人觉得Spring Web Flow只是增加开发的复杂度，本来可以通过简单的硬编辑完成的东西，为什么硬要搞出一个配置文件来，大家看看Spring Web Flow给的那个例子（http://www.ervacon.com/products/springwebflow/article/index.html），根据查询用户，然后显示详细信息的例子，本来很简单的东西 ，硬是变得复杂了许多，不但多出了很多类不多，还多出了许多配置的信息，更让人纳闷的是Spring MVC该做的东西还一件都不能少。
  
   页面控制流真的会那么复杂吗？SFW除了能够通过一个配置文件显式将隐藏在硬编码中的页面控制流程描述出来外，其它的贡献，我总觉得很廖廖。但是我们为什么一定要在程序中通过一个配置文件烘托出页面控制流程呢？－－这更象是在写文档时该做的事情。

   也许是我一已的偏见，或是此时对SWF的认识还不够清晰，请使用过SWF并感受其真的给开发带来简化的朋友谈谈感受。不欢迎人云亦云的泛泛而谈，希望看到你真实的感受的实际的经验的交流。

评论

18 楼 langds 2007-06-22  

stamen 写道

　　　谢谢大家涌跃的讨论和见解，langds对SWF应该经验丰富。从你说的经验中，可以看出你的项目本身页面流程复杂，所以使用一个复杂的SWF，反而带来了便利。那是不是可以得出这样的结论：SWF只适合于复杂页面流程的项目，而非一般的CRUD的项目呢？因为一般CRUD外带一些向导的项目，使用Spring MVC可以很好的达到要求，SWF应该不能够提供更简单的实现吧。

确切地说:是这样。正如SWF官方声明的“SWF适合的与不适合的场景”，其中最不适合的就是无流程的只有简单的crud操作的应用。比如大多数的网站就是这样，在这样的应用里引用SWF反而会带来许多不便。

17 楼 starsea 2007-06-21  

yananay大概说的是bea的page flow(jpf),我们原来用这个开发过一个项目，其实它本身就是对structs包装了一下，在一个稍微复杂一点的应用里，page flow的流程图会让第一次看的人眼花缭乱的

16 楼 stamen 2007-06-21  

　　　谢谢大家涌跃的讨论和见解，langds对SWF应该经验丰富。从你说的经验中，可以看出你的项目本身页面流程复杂，所以使用一个复杂的SWF，反而带来了便利。那是不是可以得出这样的结论：SWF只适合于复杂页面流程的项目，而非一般的CRUD的项目呢？因为一般CRUD外带一些向导的项目，使用Spring MVC可以很好的达到要求，SWF应该不能够提供更简单的实现吧。

15 楼 cwgo 2007-06-14  

虽然对SWF的认识不是很深入,但个人认为是个不错的东西,值得深入研究!

14 楼 yananay 2007-06-13  

webflow?
恐怕和 bea workshop 没法比吧。
用过 workshop，才能体会什么是flow.

13 楼 langds 2007-06-13  

downpour 写道

langds 写道

我个人认为SpringWebflow是一个相当不错的引擎,楼上的已经说swf的优点了.
我只是在此重复表示下肯定的意见. 我们项目已经在一年前开始引用SWF, 那里Webflow才刚加入到Spring, 还只是预览版本,由于系统的流程过于繁杂,我们必须要一个以流程为中心的控制引擎,否则光靠Struts和JSF这样的简单的导航控制将很难维护, 而且无法实现流程级重用. 而SWF的引入完全解决了我们的要求, 楼上有朋友说SWF使维护变成了噩耗, Action太杂等问题, 我在这里说一句公道话, 如果你的流程里写了太多的action说明你的流程设计不合理,或者说没有真正理解业务需求, SWF的流程基本上能直观地映射为业务需求上的流程. 如果你的Action太多,还说明你的Service设计有问题,每个对外暴露的service方法应该是相对独立的,能自我表达的一个或一组完速的功能. 我们的项目里,没有写任何一个业务上的ACTION. 我们有且仅有的一个Action是系统级的, 用来为字段绑定值的,但这个action在SWF 1.0.3开始就已经失去了意义,因为官方已经加入了该功能.我们的系统流程相当多,相当繁杂,还常常需要流程与流程套用和互转,如果没有SWF,我们的项目开发与维护都将很痛苦,只能回到原始的struts的分模块管理配置文件的方式,而开发人员也要写无数个无聊的Action.
PS. 我们的项目是一个金融大型项目, 也可能是国内第一个正式采用SWF的项目.(偶早在SWF还未出世前就已经在研究它的前身Webflow了,后来它加入到Spring,我从pr5版本开始正式引入到系统框架,在经过技术验证和试运行后,在1.0M2版本开始,进入应用级开发, 在1.0.3版本时,项目开发和测试完毕,正式投入生产运行.目前在1.0.4版本上运行良好.)

贴出你的代码来，不要说空话，我给你设计一个场景，Javaeye的论坛，你给我用SWF实现一下，用你所谓的不写一个Action。

To downpour.
呵呵,不好意思,我是说话不太注意用词,请哥们不要介意.
至于您给的这个场景,实在太大,我也实在没有这精力去设计一套流程出来.否则地话,我早该贴一些心得出来了.
这样吧,你能否先精简一下你目前已经有的一套你认为比较繁杂的且用了许多SWF Action的flow.大至给点注解,说明用这个action实现什么目的即可,让我们大家来看看有没有办法改进你的设计, 不知道你觉得如何?

等你的回复.

12 楼 downpour 2007-06-12  

langds 写道

我个人认为SpringWebflow是一个相当不错的引擎,楼上的已经说swf的优点了.
我只是在此重复表示下肯定的意见. 我们项目已经在一年前开始引用SWF, 那里Webflow才刚加入到Spring, 还只是预览版本,由于系统的流程过于繁杂,我们必须要一个以流程为中心的控制引擎,否则光靠Struts和JSF这样的简单的导航控制将很难维护, 而且无法实现流程级重用. 而SWF的引入完全解决了我们的要求, 楼上有朋友说SWF使维护变成了噩耗, Action太杂等问题, 我在这里说一句公道话, 如果你的流程里写了太多的action说明你的流程设计不合理,或者说没有真正理解业务需求, SWF的流程基本上能直观地映射为业务需求上的流程. 如果你的Action太多,还说明你的Service设计有问题,每个对外暴露的service方法应该是相对独立的,能自我表达的一个或一组完速的功能. 我们的项目里,没有写任何一个业务上的ACTION. 我们有且仅有的一个Action是系统级的, 用来为字段绑定值的,但这个action在SWF 1.0.3开始就已经失去了意义,因为官方已经加入了该功能.我们的系统流程相当多,相当繁杂,还常常需要流程与流程套用和互转,如果没有SWF,我们的项目开发与维护都将很痛苦,只能回到原始的struts的分模块管理配置文件的方式,而开发人员也要写无数个无聊的Action.
PS. 我们的项目是一个金融大型项目, 也可能是国内第一个正式采用SWF的项目.(偶早在SWF还未出世前就已经在研究它的前身Webflow了,后来它加入到Spring,我从pr5版本开始正式引入到系统框架,在经过技术验证和试运行后,在1.0M2版本开始,进入应用级开发, 在1.0.3版本时,项目开发和测试完毕,正式投入生产运行.目前在1.0.4版本上运行良好.)

贴出你的代码来，不要说空话，我给你设计一个场景，Javaeye的论坛，你给我用SWF实现一下，用你所谓的不写一个Action。

11 楼 xianlv 2007-06-12  

配置文件繁琐，比较适合图形化开发工具去配置生成。

SWF固然强大，但手工去写的话，得到灵活性，付出了大的工作量。直觉上感觉是得不偿失。


   个人觉得Spring Web Flow只是增加开发的复杂度，本来可以通过简单的硬编辑完成的东西，为什么硬要搞出一个配置文件来，大家看看Spring Web Flow给的那个例子（http://www.ervacon.com/products/springwebflow/article/index.html），根据查询用户，然后显示详细信息的例子，本来很简单的东西 ，硬是变得复杂了许多，不但多出了很多类不多，还多出了许多配置的信息，更让人纳闷的是Spring MVC该做的东西还一件都不能少。
/quote]

10 楼 langds 2007-06-12  

我个人认为SpringWebflow是一个相当不错的引擎,楼上的已经说swf的优点了.
我只是在此重复表示下肯定的意见. 我们项目已经在一年前开始引用SWF, 那里Webflow才刚加入到Spring, 还只是预览版本,由于系统的流程过于繁杂,我们必须要一个以流程为中心的控制引擎,否则光靠Struts和JSF这样的简单的导航控制将很难维护, 而且无法实现流程级重用. 而SWF的引入完全解决了我们的要求, 楼上有朋友说SWF使维护变成了噩耗, Action太杂等问题, 我在这里说一句公道话, 如果你的流程里写了太多的action说明你的流程设计不合理,或者说没有真正理解业务需求, SWF的流程基本上能直观地映射为业务需求上的流程. 如果你的Action太多,还说明你的Service设计有问题,每个对外暴露的service方法应该是相对独立的,能自我表达的一个或一组完速的功能. 我们的项目里,没有写任何一个业务上的ACTION. 我们有且仅有的一个Action是系统级的, 用来为字段绑定值的,但这个action在SWF 1.0.3开始就已经失去了意义,因为官方已经加入了该功能.我们的系统流程相当多,相当繁杂,还常常需要流程与流程套用和互转,如果没有SWF,我们的项目开发与维护都将很痛苦,只能回到原始的struts的分模块管理配置文件的方式,而开发人员也要写无数个无聊的Action.
PS. 我们的项目是一个金融大型项目, 也可能是国内第一个正式采用SWF的项目.(偶早在SWF还未出世前就已经在研究它的前身Webflow了,后来它加入到Spring,我从pr5版本开始正式引入到系统框架,在经过技术验证和试运行后,在1.0M2版本开始,进入应用级开发, 在1.0.3版本时,项目开发和测试完毕,正式投入生产运行.目前在1.0.4版本上运行良好.)

9 楼 langds 2007-06-12  

我用Spring Web Flow已经一年多了. 可以说我是从Spring WebFlow未出世前就在研究这东东了, 当时我发现的那个Webflow还不属于Sprng的子项目,只是后来大概从2005年底开始加入到Spring而成为子项目. 我觉得Spring Webflow相当不错, 他的流程统一调度, 状态统一管理, 一致的服务调用, 不需要写Action..., 非常好,如果没有这些,我们的系统如果只是靠struts或jsf的导航来处理那会很痛苦,基本上无法做到流程重用. 而webflow的引入完全能解决这个问题,他的重用是流程一级的.

我们没有写一个ACTION, 如果你的项目里有很多webflow的action,说明你的Service设计得很糟糕, 我们通过扩展webflow, 使页面的导航路径都是通过流程内定义好自动生成的. 我们的项目里的流程比较繁杂,通常会有流程套用的情况,如果没有它,无论是在开发阶段还是在维护阶段都会非常痛苦.而且,目前Spring webflow在我们的项目里运行得相当稳定.

PS.我们的项目是一个大型金融项目,估计应该是全国首个使用Spring Webflow的.(我在SWF前身时开始就一直在做源码级跟踪,从pr3开始集成进应用框架,经各方面验证之后, 从pr5开始试运行, 从1.0M2开始正式应用开发, 直到当前生产环境运行版本:1.0.4).

8 楼 yimlin 2007-06-09  

downpour 写道

最近在用这个产品做开发，与JSF整合。

在面对复杂的页面跳转时有一定的优势，更换配置就能轻松跳过或者增加一个新的页面流程。尤其对于那些需求经常发生改变，流程不大清楚的时候，修改的代价比较小。

它的问题不在于配置繁琐，要论配置繁琐，它和传统的MVC框架其实也差不到哪里去。因为按照这个框架本身的想法，就希望用配置来代替在一个Flow中复杂的HttpSession的状态操作。因为类似Struts1.x或者Webwork，它们在针对Wizard流程页面上都免不了需要在Action中重复大量的HttpSession操作来保存或者回退某个步骤的操作。而这点在Spring Web Flow中可以大量简化。

我现在用下来觉得Spring Web Flow最大的问题在于这个框架本身设计得比较死板，很多情况下，不得不在我们的Action或者页面上穿插恶心的操作Flow的代码，甚至这样的代码还要延伸到配置文件中，这个是我非常不能接受的，因为代码一旦四散在各处，就很难进行维护和修改。同样，也会造成你一看他的配置文件就不想再对这个项目产生任何兴趣了。另外它的很重要的问题是适用面比较狭窄，应对简单的增删改查页面，它的配置就变成噩梦了。

我也在使用SWF,不完全同意你的观点;
我把SWF看成是一个机会,正是因为框架的这种设计,迫使我们必须去考虑如何设计我们的对象.

因为做的项目是企业应用,这类项目的特点是业务流程化明显.
在没有SWF,而在使用Struts时候,我们不也一样在action中控制流程,甚至在JSP文件中做控制,(当然受限于Struts,不会出现代码延伸到配置文件中).

SWF的出现带来一个显示的page flow的定义能力(Struts中比较难获取这样的信息),在flow定义文件中控制流程.

我以为这才是SWF的目的:把流程控制逻辑和业务调用逻辑分离开,并集中控制在一点; 至于HttpSession的状态操作是SWF的一大特色,它是手段,但不是目的.

因此在使用SWF实践中,我们就不再写Action了(SWF的Action),通常由SWF直接调用Service类,JSP页面上也没有流程控制逻辑;

当出现配置文件复杂的情况时,我们就开始考虑,这个流程在逻辑是否真的这么复杂吗?是否是我们的service类以及model类没有写好,接口不够人本(当然我们不会为了页面流去改变我们的service以及model类);

如果都不是,提供一个pojo的对象(封装了一部分调用逻辑)给swf调用能否一定程度上简化(就像我们在Spring MVC以及Webwork中做的那样).

BTW:SWF不仅仅可以用statefull的流程上,stateless的流程上也可以用,不用SWF提供的httpsession操作就可以了.

7 楼 galaxystar 2007-06-09  

还是喜欢turbine风格!

6 楼 stamen 2007-06-09  

   在我所经历的项目中，很少需要“复杂”页面控制的（我不知道如何定义这个复杂），常见的比较难实现的是向导式流程，即通过填写一系列表单完成一个功能，可以返回和前进，每步需要校验，但这种需求已经在Spring MVC的向导控制器中完美地实现了，它比SWF要优雅简单很多。所以在一般项目中，我真的很难为SWF想出它的用武之地。

5 楼 zyl 2007-06-07  

对于page状态保留的情况，一般的web页面很少使用，除了向导页面。大多数都是无状态的。不过集中的页面流管理，相对于分散的代码。还是有必要的。这就是为什么jsf，会采用navigate，而不是像structs简单的页面和动作的映射关系而已。

4 楼 JJYAO 2007-06-06  

Page Flow可分为Stateless Page Flow和Statefull Page Flow
Stateless Page Flow只需要维护导航逻辑即可,一般针对网站式的自由链接应用
而Statefull Page Flow除了导航逻辑外，还需要维护conversation信息，所以，相对复杂点。
感觉LZ的项目可能只需要Stateless Page Flow即可，典型的就是JSF的Navigate。而SWF主要针对Statefull Page Flow应用

3 楼 wl95421 2007-06-06  

推荐你去看一下Wicket提供的向导例子
感觉比SWF要简单很多

2 楼 stamen 2007-06-06  

downpour 写道

最近在用这个产品做开发，与JSF整合。

在面对复杂的页面跳转时有一定的优势，更换配置就能轻松跳过或者增加一个新的页面流程。尤其对于那些需求经常发生改变，流程不大清楚的时候，修改的代价比较小。
...
。

   谢谢downpour的回复,确实是切身的经验!
   如果说SWF只合适于复杂的页面流程的需求,这种复杂页面流程的需求数本身并不会太多,是否有必要
因为系统中有一个复杂的页面流程控制需求就引入这样一个框架呢?现在我很害怕的一件事是,一个项目中
开源框架真的太多了,Spring,Struts,Hibernate已经让我穷于应付,DWR,Acegi,XFire等等让一个项目变得越来越难以驾驭.为了一个本身可以自行处理的需求新增一个新框架是否值得,这是一个很值得探讨的问题.  
    毕竟大多数项目的大多数功能都是CRUD,大多数是简单的页面控制,是否真的存在一个非用SWF不可的项目呢?(意思是说用了之后确实节省大量的开发时间),我对此非常怀疑.请深切体会的兄弟举出自己的例子,谢谢.

1 楼 downpour 2007-06-06  

最近在用这个产品做开发，与JSF整合。

在面对复杂的页面跳转时有一定的优势，更换配置就能轻松跳过或者增加一个新的页面流程。尤其对于那些需求经常发生改变，流程不大清楚的时候，修改的代价比较小。

它的问题不在于配置繁琐，要论配置繁琐，它和传统的MVC框架其实也差不到哪里去。因为按照这个框架本身的想法，就希望用配置来代替在一个Flow中复杂的HttpSession的状态操作。因为类似Struts1.x或者Webwork，它们在针对Wizard流程页面上都免不了需要在Action中重复大量的HttpSession操作来保存或者回退某个步骤的操作。而这点在Spring Web Flow中可以大量简化。

我现在用下来觉得Spring Web Flow最大的问题在于这个框架本身设计得比较死板，很多情况下，不得不在我们的Action或者页面上穿插恶心的操作Flow的代码，甚至这样的代码还要延伸到配置文件中，这个是我非常不能接受的，因为代码一旦四散在各处，就很难进行维护和修改。同样，也会造成你一看他的配置文件就不想再对这个项目产生任何兴趣了。另外它的很重要的问题是适用面比较狭窄，应对简单的增删改查页面，它的配置就变成噩梦了。