Spring Web Flow 的优势是什么？答案

【问题标题】：What are the Spring Web Flow advantages?Spring Web Flow 的优势是什么？
【发布时间】：2015-06-27 08:18:00
【问题描述】：

谁能帮我理解 Spring Web Flow 的优点。我的理解是

所有流程都可以集中配置在一个 XML 文件中。
不需要将数据从一个请求转移到另一个请求的开销，因为它可以通过流范围来完成。
在面包屑导航等情况下尤其有用。
可以将流进一步划分为子流以降低复杂性。

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

【问题讨论】：

顺便说一句，除非您已经了解 Spring MVC，否则我不建议您使用 Spring Webflow。有些东西不是很直观/没有构建。例如，我仍然不知道如何正确地将流程恢复到用户上次离开的地方。配置 XML 与配置普通 Spring 配置的方式也不同。您的 URL 也成为基于执行的 URL，因此直接引用页面并不容易。

【解决方案1】：

我将扮演魔鬼的拥护者并说除了简单的用例之外不要将其用于任何其他用途。简单的用例意味着没有 ajax 调用，没有模式对话框，没有部分更新，只是标准 html 表单/流以实现简单的持久性（即页面 A -> 页面 B -> 页面 C，其中每个“页面”映射到视图状态定义1 对 1 关系都定义在同一个流 xml 文件中）。

Spring webflow 缺点：

是的，理论上一切都在 xml 文件中，这应该很简单，但是当您有多个流 xml 文件时，每个文件都有多个状态定义和可能的子流定义，维护或轻松确定顺序逻辑会变得很麻烦一个流是。（有点像旧的“GOTO 运算符”，其中流逻辑的任何部分都可以跳回任何先前或以后定义的部分，使流逻辑虽然在 xml 中看似“顺序”......但不直观）
Spring Webflow 文档的某些功能不直观或完全没有文档记录，导致数小时的反复试验。例如，异常处理、“输出”标签的使用（仅适用于子流程->返回未记录的父调用者）、向用户发送回 Flash 视图响应也是不直观的，并且使用与 Spring MVC 不同的容器（很多时候当流程结束您想向 webflow 之外的控制器中定义的用户发送一条消息……但是由于流程结束了，您无法在 spring webflow 中使用 flashScope 容器执行此操作）等等……
虽然听起来不错，但添加子流并不会降低复杂性，实际上会增加复杂性。由于定义子流的方式。定义又长又复杂，当您在主父流和子子流中都有许多最终状态时，可能会造成混淆。
如果与某些 3rd 方视图框架（如 Apache Tiles 或 Theymeleaf）集成，初始设置和配置可能会很痛苦……我记得在这上面花了几个小时甚至几天。
状态快照（保存用户在页面之间的输入）虽然来自流程 A 的 view-state_1 流程 A 的 view-state_2 的强大功能，反之亦然。这在 Main Flow A Sub Flow B 之间不起作用，反之亦然……迫使开发人员手动绑定（或者更确切地说是破解）在 Parent 主流的子流之间保存用户的状态。
调试放置在 webflow 中的应用程序逻辑可能很困难。例如，在 webflow 中，您可以使用 xml 中的 SPEL 分配变量并执行条件检查，但这往往是一个陷阱。随着时间的推移，您学会了避免将应用程序逻辑放在实际的 webflow xml 中，并且只使用 xml 来调用服务类方法并将返回的值放在各种范围内（同样，这个艰难的教训/最佳实践没有记录在案）。此外，因为您正在使用 SPEL 执行逻辑...重构类、方法名称或变量有时会默默地破坏您的应用程序，从而显着增加您的开发时间。
片段渲染... webflow 的一个强大但不直观的功能。设置片段渲染是我在使用 webflow 时最痛苦的事情之一。缺乏文件。我认为如果这个功能有更好的文档并且易于设置，它可以很容易地进入专业领域。我实际上记录了如何通过 stackoverflow 使用此功能...How to include a pop-up dialog box in subflow
每个流的静态 URL。如果您的流程在 1 个流程中定义了多个视图，则您的 URL 不会从视图状态导航到视图状态。如果您想使用动态 url 控制或匹配页面内容，这可能会受到限制。
如果您的流程在“/WEB-INF/flows/doSumTing/sumting-flow.xml”中定义，并且您的“基本路径”设置为“WEB-INF/flows”。然后导航到您的流程，您转到 http://<your-host>/<your-webapp-name-if-defined>/doSumTing 。流文件名被完全忽略，根本没有在 URL 中使用。虽然现在很清楚，但当我第一次开始时，我发现这不直观。

Spring Webflow 专家：

“范围”容器 flowScope、viewScope、flashScope、sessionScope 的概念以及轻松访问这些容器随处可见为开发人员提供了灵活性，因为它们可以从任何地方访问并且是可变的.
轻松定义状态视图-状态、操作-状态、决策-状态、结束-状态，清楚地定义每个状态正在做什么，但正如缺点中所述...如果您的应用程序很复杂并且有很多不同状态和转换不断地来回走动......这会使您的 -flow.xml 文件变得混乱，从而难以阅读或遵循顺序逻辑。只有当您有包含少量状态定义的简单用例时，这才容易。
很少使用但 webflow 的一个强大功能是流继承。跨多个流的通用流功能可以在单个抽象父流中定义并由子流扩展（类似于 java 中的抽象类定义）。如果您有许多共享通用逻辑的流程，则此功能非常适合 DRY 原则。
易于定义的验证规则和对 JSR-303 的支持（但 Spring MVC 也有）
输出标签可用于在主流子流之间来回发送POJO。这个特性很好，因为参数不需要通过 get/post 通过 url 传递，并且可以传递任意数量的 POJO。
明确定义的视图。视图名称是什么以及它被映射到哪个模型变量（例如 <view-state id="edit" view="#{flowScope.modelPathName}/editView" model="modelObj"> ）。同样在刚刚演示的示例中，可以对视图名称或 webflow 中的大多数参数使用预处理表达式...虽然没有很好的文档记录，但还是不错的功能：/

结论： Spring Webflow 项目是一个好主意，在纸面上听起来很棒，但缺点是在复杂的用例中使用起来很麻烦，从而显着增加了开发时间。由于对我来说存在针对复杂用例 (Spring MVC) 的更好解决方案，因此不值得在 Web 流上进行大量投资，因为您可以使用 Spring MVC 实现相同的结果，并且对于复杂和简单的用例都具有更快的开发时间。此外，Spring MVC 得到积极维护，拥有更好的文档和更大的用户社区。也许如果我的一些缺点得到解决，它会倾向于 Webflow，但在那之前我会推荐 Spring MVC 而不是 webflow。

注意：我可能会遗漏一些东西，但这是我脑海中想到的。

【讨论】：

我会按照我或其他人的建议编辑答案或添加更多的缺点/优点。
是否有使用 Spring MVC 并支持后退按钮的解决方法？您在结论中提到了这一点。
@bphilipnyc 不，我实际上并没有在结论中提到这一点，但我在第 5 节的缺点中提到了。这是一个不错的功能，但对我个人而言，我很少使用它（因此很少重视它），但我认为其他人的价值是 webflow。因此，如果这是即将到来的项目中必须具备的功能，那么可以使用 webflow，但我真的相信这是少数用例。在 Spring MVC 中，您可以做的最接近（但仍远未匹配快照）的事情是使用 @SessionAttribute("myModel") 注释。
对 - 我指的是你在结论中提到的 Spring MVC。听起来我们同意。
@bphilipnyc 是的，webflow 仍然是一个很有前途的项目。也许如果他们有时间对主要修订版（3.0）进行大修，并且可以选择更紧密的 Spring MVC 集成，我想我会很容易地在我的所有用例中重新使用它。

【解决方案2】：

此外，您可以使用后退按钮并将状态保留到您选择存储的快照数量。

您也可能会发现this related question 很有用。

【讨论】：

Saverio，它怎么不回答这个问题？使用后退按钮来存储快照是 Spring Web Flow 的一个优势，这是列表中缺少的，也是我个人在项目中使用它的主要原因。