Seam无缝集成：为JSF定做应用程序框架 - 编程入门网

Seam 引入了工厂数据提供者（factory data provider）的概念，工厂数据提供者由 @Factory Java 5 注释指定。虽然有两种方法配置工厂，但是最终结果是同样的数据只需在第一次被请求时准备一次。 Seam 确保随后对相同数据的请求将直接返回之前创建的结果集，而不必再一次触发对查找方法的调用。通过与 conversation 相结合，工厂数据提供者成为实现数据短期缓存的非常强大的特性，否则，取这些数据的代价可能较高。在 JSF 不负责减少它解析一个值绑定表达式的次数的情况下，Seam 的工厂特性常常变得非常方便。

有状态 conversation

关于 JSF 很容易引起困惑的一个地方是它的状态管理功能。JSF 规范解释了在接收一个动作之后页面是如何 “恢复（restored）” 的，在此期间时间事件要进行排队，选择要注册。仔细研究规范中的用词可以发现，虽然在 postback 上恢复了组件树，但是那些组件使用的 backing bean 数据并没有被恢复。组件只是以字符串文字的形式存储值绑定（使用 #{value} 语法的 EL 表达式），只在运行时解析底层数据。这意味着如果一个值是短期作用域存储的，例如页面或请求作用域，那么当 JSF 生命周期到达 Restore View 阶段时，这个值将消失。

不将值绑定数据存储在组件树中的一个最值得注意的不利方面是虚幻事件效果（见 参考资料），这是由 UIData 家族中的临时父组件导致的。如果一个值绑定表达式引用的模型数据不再可用，或者在组件树被恢复之前发生了更改，那么组件树的一些部分将被撤销。如果在这些被撤销的分支中，有一个组件中触发了一个事件，那么它将不能被发现，而且这种事件丢失情况是难于觉察的。（只是队列开发人员可能会惊呼 “为什么我的动作没有被调用？”）

虽然丢失的事件看上去像是异常状况，但并不会导致 JSF 生命周期中出现红色标志。因为这些组件依赖底层数据，以保持稳定和适当地被恢复，所以 JSF 难于知道丢失了什么。

不幸的是，JSF 规范天真地引导开发人员将大多数 backing bean 放入 conversation 作用域中 —— 甚至可以在 “方便的” 作用域内调用它。然后，服务器管理员则必须处理由此导致的 “内存溢出” 错误，集群环境中的服务器相似性，以及服务器重启时的串行化异常。MyFaces Tomahawk 项目通过 t:saveState 标记的形式提供了对虚幻事件的一个解决方案。MyFaces 标记允许将数据（包括整个 backing bean）存储为组件树的一部分，而仅仅是值绑定。然而，这种解决方案有些简陋，很像使用隐藏的表单字段在请求之间传递值。它还造成视图与控制器之间紧密耦合。Seam 的创立者意识到，Java Servlet 规范中三个内置的上下文（请求、会话和应用程序）不足以构成数据驱动的 Web 应用程序的全部作用域。在 Seam 中，他们引入了 conversation 作用域，这是一个有状态作用域，由页面流的起止点界定。

Seam 的 conversation 作用域

“Seam 强调使用有状态组件。” Seam 参考文档中的这句话体现了 Seam 的核心思想。很长一段时间内，关于 Web 应用程序的看法是，它们是无状态的 —— 这种思想一定程度上要归因于 HTTP 协议的无状态性质。大多数框架为了迎合这一点，在结束页面呈现之前提供 one-shot-processing。这种方法导致很大的阻力，因为任何大的应用程序都需要长时间运行的 conversation 来满足某些用例。需要有状态上下文的应用程序的例子有很多，例如存储检查过程、产品定制、多页表单向导和很多其他基于线形交互的应用程序。虽然其中有些例子可以通过使用 URL 参

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!