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

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

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

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

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

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

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

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

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

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应用

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

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

还是喜欢turbine风格!

我也在使用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操作就可以了.

我用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).