spring-webflow - Spring Web Flow的优势是什么？

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

Spring webflow缺点：

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

Spring Webflow专业人士：

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

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

注意：我可能会遗漏一些东西，但这是我想到的最重要的事情。

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

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

Spring Web Flow的优势是什么？

2 个答案: