Spring Web Flow的优势是什么？

Question

有人可以帮我理解Spring Web Flow的优点.我所理解的是

1. 可以在XML文件中集中配置所有流.
2. 不需要将数据从一个请求转移到另一个请求的开销,因为它可以通过流范围来完成.
3. 它尤其适用于像Breadcrumbs导航这样的情况.
4. 流可以进一步划分为子流以降低复杂性.

还有其他我没有调整过的吗？

Answer 1

我将扮演魔鬼的拥护者,并说不要将它用于除简单用例之外的任何事情.简单的用例意味着没有ajax调用,没有模态对话框,没有部分更新只是简单持久性的标准html表单/流程(即页面A - >页面B - >页面C,其中每个'页面'映射到视图状态定义中所有在同一个流xml文件中定义的1对1关系).

Spring webflow缺点:

1. 是的,一切都在xml文件中理论上它假设很简单但是当你有多个流xml文件时,每个文件都有多个状态定义和可能的子流定义,维护或轻松确定流的顺序逻辑是多么麻烦.(有点像旧的"GOTO操作符",其中流逻辑的任何部分都可以跳回到任何先前或以后定义的部分,使得流逻辑虽然在xml中看似"顺序"...但是不直观地遵循)

2. Spring Webflow文档的某些功能不直观或没有记录,导致数小时的试验和错误.例如,异常处理,输出'输出'标签(仅在子流中工作 - >返回到未记录的父调用者),向用户发送回闪存视图响应也是不直观的并且使用与Spring MVC不同的容器(很多时候是流程结束你想发送一个msg给在webflow之外的控制器中定义的用户...但是由于流程结束了你无法在使用flashScope容器的spring webflow中执行它等等...

3. 添加子流虽然听起来不错但不会降低复杂性实际上会增加它.由于子流的定义方式.定义很长且很复杂,当主父流和子子流都有很多结束状态时,定义会很混乱.

4. 如果与某些第三方视图框架(如Apache Tiles或Theymeleaf)集成,则初始设置和配置可能会很痛苦...我记得花费几个小时(如果不是几天).

5. 状态快照(保存用户在页面之间的输入)虽然Flow A的视图中有一个强大的功能 - state_1 < - > Flow A的视图 - state_2,反之亦然.这在Main Flow A < - > Sub Flow B之间不起作用,反之亦然......迫使开发人员手动绑定(或者说是hack)在Parent main flow的< - >子流之间保存用户的状态.

6. 调试Webflow内部的应用程序逻辑可能很困难.例如,在webflow中,您可以使用xml中的SPEL分配变量并执行条件检查,但这往往是一个陷阱.随着时间的推移,您将学会避免将应用程序逻辑放在实际的webflow xml中,并且只使用xml来调用服务类方法并将返回的值放在各个范围内(同样,这个难以学习的课程/最佳实践也没有记录).此外,因为您正在使用SPEL执行逻辑...重构类,方法名称或变量有时会无声地破坏您的应用程序,从而显着增加您的开发时间.

7. 片段渲染...... webflow的一个强大但不直观的特性.设置片段渲染是我用webflow做的最痛苦的事情之一.文档缺乏.我认为如果更好地记录并且易于设置,这个功能可以很容易地进入专业方面.我实际上记录了如何通过stackoverflow使用此功能... 如何在子流中包含弹出对话框

8. 每个流的静态URL.如果您的流具有在1流中定义的多个视图,则您的URL将不会更改从视图状态导航到视图状态.如果您想使用动态网址控制或匹配网页内容,则可能会受到限制.

9. 如果您的流程在"/WEB-INF/flows/doSumTing/sumting-flow.xml"中定义,并且您的"基本路径"设置为"WEB-INF/flows".然后导航到您转到的流程http://<your-host>/<your-webapp-name-if-defined>/doSumTing.流文件名完全被忽略,根本不在URL中使用.虽然现在很清楚,但是当我第一次开始时,我发现这不直观.

Spring Webflow专业人士:

1. "范围"容器的概念flowScope,viewScope,flashScope,sessionScope以及轻松访问这些容器WITH IN A FLOW为开发人员提供了灵活性,因为这些容器可以从任何地方访问并且是可变的.

2. 轻松定义状态视图状态,动作状态,决策状态,结束状态,清楚地定义每个状态正在做什么,但正如缺点中所提到的......如果您的应用程序很复杂且具有许多不同的状态和转换不断回头...这会使你的-flow.xml文件变得混乱,使得难以阅读或遵循顺序逻辑.只有具有少量状态定义的简单用例才会很容易.

3. 很少使用,但webflow的一个强大功能是流继承.跨多个流的公共流功能可以在单个抽象父流中定义,并由子流扩展(类似于java中的抽象类定义).如果您有许多共享共同逻辑的流,则此功能在DRY原则方面很好.

4. 轻松定义的验证规则和对JSR-303的支持(但Spring MVC也有此功能)

5. 输出标记可用于在主流< - >子流之间来回发送POJO.此功能很不错,因为参数不需要通过get/post传递给url,并且可以根据需要传递尽可能多的POJO.

6. 明确定义的观点.视图名称是什么以及它被映射到哪个模型变量(例如 <view-state id="edit" view="#{flowScope.modelPathName}/editView" model="modelObj">).另外在刚刚演示的示例中,可以使用预处理表达式来查看网页流中的视图名或大多数参数...虽然没有很好的记录,但是很好的功能:/

结论: Spring Webflow项目是一个好主意,并且在纸面上听起来很棒,但是在复杂的用例中使用繁琐,显着增加了开发时间.由于对于复杂的用例(Spring MVC)存在更好的解决方案,因此不值得在Web流程中投入大量资金,因为您可以使用Spring MVC获得相同的结果,并且可以更快地开发复杂和简单的用例.更重要的是,Spring MVC得到了积极的维护,拥有更好的文档和更大的用户社区.也许如果我的一些缺点得到解决,它会在Webflow的帮助下缩小规模,但在那之前我会推荐Spring MVC而不是webflow.

注意:我可能会遗漏一些东西,但这是我想到的最重要的事情.