WebFlow 在某种意义上是灵活的,您可以通过“进入”和“退出”标签或在动作状态标签中执行任何状态下的评估表达式。与任何允许灵活性的框架一样,最好选择在所有流程中都一致的策略。您可以简单地在“view-state”内的“on-entry”或“on-render”标签内执行评估表达式,但使用中间“action-state”先在那里执行表达式然后转换到'视图状态'。
优势:
有时您必须评估多个表达式,但它们都是同一个“动作”的一部分。将这些多个评估分组到“动作状态”中并为“动作状态”提供有意义的 id 名称可能有助于流的可读性和潜在的故障排除,如果在该动作状态中引发异常的话。
例如,
假设我们必须在渲染“视图状态”之前调用 3 个不同的服务方法。我们可以这样做:
<view-state id="myViewState" view="myViewFile" model="entity">
<on-entry>
<evaluate expression="myService.findObjById(id)" result="flowScope.model" />
<evaluate expression="myService.updateUserStats(someField)"/>
<evaluate expression="myService.performSomeOtherAction()"/>
</on-entry>
</view-state>
这会很好,但是如果我们从“on-entry”中删除所有这些服务方法调用并在完成执行后将它们置于自己的“action-state”然后转换到“view-state”会更好'
<action-state id="prepareMyViewState">
<evaluate expression="myService.findObjById(id)" result="flowScope.model" />
<evaluate expression="myService.updateUserStats(someField)"/>
<evaluate expression="myService.performSomeOtherAction()"/>
<transition to="myViewState"/>
</action>
<view-state id="myViewState" view="myViewFile" model="entity">
</view-state>
这两个例子都是“正确的”,但是带有动作状态的例子更加冗长,并且清楚地定义了关注点的分离。因此,如果在动作状态“prepareMyViewState”中引发异常,我们从名称中确切地知道该动作状态的作用,而不是视图状态“myViewState”引发的异常,这可能与准备或视图状态的渲染。此外,将来如果您想添加/编辑/删除服务调用,您可以轻松地在流文件中发现它,当它们以有意义的名称“prepareMyViewState”置于自己的操作状态时。
再次强调,这里没有错误的答案,我只想说选择一种在整个 Web 流应用程序中保持一致的“风格”。具有中间动作状态的第二种样式是我将使用的样式。