java - 对话范围是 View 范围的合适替代品吗？

Question

在 JSF 2.0 中， View 范围最明显的用例是具有潜在多个 AJAX 回发的单个页面。使用 CDI 而不是 JSF 托管 beans 使我们没有 View 范围，因此我们要么实现自己的，要么使用(可能是错误缠身的)第三方实现，要么使用对话范围。

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

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

更新

对话范围确实支持每个 session 的多个实例。 This book状态一样多，我能够使用来自 ch 的代码来确认这一点。 2.

Answer 1

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

@Inject
private Conversation conversation; 

无论何时你想开始对话，你都需要检查 bean 是否处于 transient 状态。否则，将抛出 IllegalStateException。它会是这样的:

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

通过这样做，您的 bean 将处于 long-running 状态。因此，如果用户离开页面并稍后返回，您始终可以检查他的对话是否超时并将他带到他离开的页面。

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

更新:

Is the conversation scope a worthy substitute for the view scope in the typical AJAX situation?

我不认为 @ConversationScoped 可以完全取代 @ViewScoped。

Like the view scope, does it allow multiple instances per session?

不，每个 session 不能有多个实例。正如我提到的，如果您在旧对话仍处于 long-running 状态时开始新对话，您将得到 IllegalStateException。

What are the pitfalls?

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