在 JSF 2.0 中，视图范围最明显的用例是具有潜在多个 AJAX 回发的单个页面。使用 CDI 而不是 JSF 托管 bean 使我们没有视图范围，因此我们要么实现自己的，要么使用（可能存在错误的）第三方实现，要么使用会话范围。
我的问题：在典型的 AJAX 情况下，对话范围是否值得替代视图范围？像视图范围一样，它是否允许每个会话有多个实例？有什么陷阱？
我知道其中一个陷阱，即当用户离开页面时对话范围不会自动删除，而是在超时后被删除。但我不确定当用户在对话超时之前返回该页面时会发生什么。
更新
对话范围确实支持每个会话的多个实例。 This book 声明了很多，我可以使用来自 ch 的代码来确认这一点。 2.
【问题讨论】：
标签： java jsf-2 cdi conversation-scope
在任何@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 注入到MangedBean。我不认为你可以反过来做。无论如何，我不知道这是否会导致以后发生任何不好的事情。但是，到目前为止，我从未遇到任何问题。如果你真的想用@ViewScoped，我想你可以试试：P。
更新：
在典型的 AJAX 情况下，对话范围是否值得替代视图范围？
我认为@ConversationScoped 永远无法完全取代@ViewScoped。
与视图范围一样，它是否允许每个会话有多个实例？
不，每个会话不能有多个实例。正如我所提到的，如果您在旧对话仍处于long-running 状态时开始新对话，您将获得IllegalStateException。
有什么陷阱？
嗯，@ViewScoped 相对于@RequestScoped 的主要优势之一是您无需在每次用户将表单提交到同一个视图时重新启动数据。但是，对于@ConversationScoped，这个优势被过度使用了。虽然这个问题不像使用@SessionScoped 那样严重，但只要@ConversationScoped bean 存在，您仍然需要保存已启动的数据。对话时间越长，您可能需要持有的数据就越多。
【讨论】：
@EJB。这适用于CDI beans 和ManagedBean。此外，使用CDI 的原因与管理JSF 范围无关。更重要的是您可以向 CDI bean 注入更多的东西。