spring-webflow - Spring Web Flow有哪些优势？

Question

有人可以帮助我了解Spring Web Flow的优点。
我了解的是


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


还有其他我尚未调整的内容吗？

Answer 1

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

Spring Webflow缺点：


是的，理论上一切都在xml文件中，这很简单，但是当您有多个流xml文件时，每个文件都有多个状态定义以及可能的子流定义，那么维护或轻松确定流的顺序逻辑可能变得很麻烦。 （有点像旧的“ GOTO运算符”，其中流逻辑的任何部分都可以跳回到任何先前或以后定义的部分，从而使流逻辑成为可能，尽管在xml中看似“顺序” ...难以理解）
Spring Webflow文档的某些功能不直观，或者完全没有文档，这会导致数小时的反复试验。例如，异常处理，使用'output'标签（仅适用于未记录的subflow->返回父调用方），向用户发送回flash视图响应也是不直观的，并且使用与Spring MVC不同的容器（很多时候流程结束时，您想向在webflow之外的控制器中定义的用户发送消息...但是由于流程结束，因此您无法在Spring webflow中使用flashScope容器来执行此操作，等等）
尽管听起来不错，但添加子流并不会降低复杂性，实际上却增加了它。由于定义了子流的方式。当您在主父流和子子流中都有许多最终状态时，定义又长又复杂，可能会造成混淆。
如果与某些第三方视图框架（如Apache Tiles或它们）集成，则初始设置和配置可能会很麻烦。我记得在此花费了数小时甚至数天。
状态快照（保存用户在页面之间的输入），尽管来自Flow A的view-state_1 <-> Flow A的view-state_2的强大功能，反之亦然。这在主流程A <->子流程B和反之亦然之间不起作用...强制开发人员手动绑定（或更确切地说，是hack），以在父主流程的<->子流程之间保存用户状态。
调试放置在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/summing-flow.xml”中定义了流，并且“基本路径”设置为“ WEB-INF / flows”。然后导航到您的流程，请转到http://<your-host>/<your-webapp-name-if-defined>/doSumTing。流文件名将被完全忽略，并且根本不会在URL中使用。尽管现在很清楚，但是我刚开始时发现这并不直观。


Spring Webflow的优点：


“范围”容器的概念flowScope，viewScope，flashScope，sessionScope以及可以方便地访问这些容器，从而使开发人员具有灵活性，因为它们可以从任何地方访问并且是可变的。
轻松定义状态view-state，action-state，decision-state，end-state，这些状态清楚地定义了每个状态的工作，但是在cons中提到了...如果您的应用程序很复杂并且具有许多不同的状态和转换，则请继续来回...这会使您的-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。

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