对话范围是否可以适当替代视图范围？

Question

在 JSF 2.0 中，视图范围最明显的用例是具有潜在多个 AJAX 回发的单个页面。使用 CDI 而不是 JSF 托管 bean 会使我们失去视图范围，因此我们要么自己实现，要么使用（可能存在错误的）第三方实现，要么使用会话范围。

我的问题：在典型的 AJAX 情况下，对话范围是否值得替代视图范围？与视图范围一样，它是否允许每个会话有多个实例？有哪些陷阱？

我知道其中一个陷阱，即当用户离开页面时，对话范围不会自动删除，而是在超时后删除。但我不确定当用户在对话超时之前返回该页面时会发生什么。

更新

对话范围确实支持每个会话多个实例。 这本书说明了这一点，我可以使用 ch 中的代码来确认这一点。 2.

Answer 1

在任何@ConversationScoped CDI bean中，您必须具有以下字段：

@Inject
private Conversation conversation; 

每当您想要开始对话时，您都需要检查bean是否处于瞬态状态。否则，将抛出IllegalStateException。它会是这样的：

public void beginConversation() {
  if (conversation.isTransient()) conversation.begin();
}

通过这样做，您的 bean 将处于长时间运行状态。因此，如果用户离开该页面并稍后返回，您可以随时检查他的对话是否超时，并将他带到他离开的页面。

此外，我已经将 @ViewScoped ManagedBean 与 CDI bean 一起使用了一段时间。您仍然可以使用 @Inject 将 CDI bean 注入到 MangedBean 中。但我认为你不能采取相反的做法。无论如何，我不知道这是否会导致以后发生任何不好的事情。然而，到目前为止，我还没有遇到任何问题。如果你真的想使用@ViewScoped，我想你可以尝试：P。

更新：

在典型的 AJAX 情况下，对话范围是否值得替代视图范围？

我认为 @ConversationScoped 无法完全取代 @ViewScoped。

与视图范围一样，它是否允许每个会话有多个实例？

不可以，每个会话不能有多个实例。正如我所提到的，如果您在旧对话仍处于长时间运行状态时启动新对话，您将收到 IllegalStateException。

有哪些陷阱？

嗯，@ViewScoped 相对于 @RequestScoped 的主要优点之一是，每次用户将表单提交到同一个视图时，您不需要重新启动数据。然而，对于@ConversationScoped，这个优势被过度利用了。虽然这个问题不像使用 @SessionScoped 那样严重，但只要 @ConversationScoped bean 存在，您仍然需要保存启动的数据。对话时间越长，您可能需要保存的数据就越多。