对 Web 应用开发人员来说,状态管理一直是一个挑战。对话应该在应用层而不是请求层来处理交互。Jacob Orshalick 以 Seam 的酒店预订示例应用为例,论述了 Seam 的对话模型,并解释了如何将嵌套对话运用于该示例。
Seam 的对话模型提供了一个简化方法来处理 continuations。如果你熟悉 continuation server 的概念,你就知道它们提供了包括无缝后退按钮处理和自动状态管理在内的功能。一个用户会话有很多 continuations,它们是执行过程中简单的状态快照,可在任何时候恢复。如果你对这个概念不熟悉,别担心,Seam 使其变得很简单。
这只是模型的一部分,Seam 还允许对话的嵌套:
嵌套对话提供了一个状态容器,它堆叠在最早的对话或外部对话的状态容器之上。任何在嵌套对话状态容器中设置的对象,都不影响可从父对话状态容器中访问的对象。这就允许每个嵌套对话能保持其自己独有的状态。
Orshalick 从定义嵌套对话到确保它被妥善地清空一路演示下来。他用 JBoss Developer Studio 来扩展 Seam 的酒店预订示例应用,生动地完成了嵌套对话的讲解。
Jacob Orshalick 不止澄清了嵌套对话,他还讨论了对话超时的话题:
对话超时似乎是一个普遍被误解的 Seam 概念。在 Seam 论坛上,我常常看见一些帖子宣称对话超时不起作用。实际上它工作得很正常,只不过你必须去理解它的语义。
Orshalick 用与嵌套对话相同的例子说明了,在处理多对话时,只有后台对话会受到对话超时的影响。照这样来说,只有会话本身超时时,前台对话才会超时。
Orshalick 最后总结到:
通过其简单的对话模型,Seam 提供了一个非常有吸引力的方法来管理状态。过去开发人员艰难处理的复杂问题,包括多窗口操作和后退按钮处理,都能处理得天衣无缝了。
查看英文原文: Understanding Seam Nested Conversations and Timeouts - - - - - -
译者简介: 王丽娟(Ivy Wang),一个快乐的程序员,持续从事 Java EE 中间件和 Java EE 企业应用的开发,关注软件架构技术。职业目标是成长为一名优秀的架构师。
评论