Seam 为JSF量身定做的应用程序框架

　　JSF 正开始凭借其 Web 标准的地位主导 Web 应用程序市场。随着更多的开发人员受托使用 JSF 作为基础来架构应用程序，他们发现 JSF 的核心规范中清楚地说明： JSF 不是为成为一个完整的 Web 应用程序框架而设计的。相反，它提供一个健壮的、事件驱动的 API 和 UI 组件库，用于构建更复杂的应用程序框架。

　　我在寻找用于弥补 JSF 的组件驱动架构的扩展时，发现 Shale 和 Struts 2 都有不足之处。我排除了 Struts 2，因为它将 JSF 看作是面向更大范围的设计。而 Shale 似乎更靠近一些，它基本上是基于 JSF，但是 对此我持保留意见。相反，JBoss Seam 是一个全面的应用程序框架，它构建在 JSF 的基础上，但是并没有损害它的核心目标。

　　寻找 Seam

　　刚刚阅读到关于 JBoss Seam 的文章的第一页，我就知道 Seam 正是我要找的项目。Seam 的开发人员，尤其是 Gavin King，在经过足够多的、实际的开发之后，知道一个 Web 应用程序框架必须从一开始就攻破难题，包括上下文状态管理、RESTful 和用户友好的 URL、Ajax remoting、适当的异常处理和约定优于配置。令 Java 开发人员欣喜的是，Seam 可以满足所有这些需求，甚至可以满足更多需求。如果您正使用 JSF，并且还没听说过 Seam，那么我强烈建议您看看 Seam 的参考文档。Seam 附带的手册就是最好的资料!

　　尽管 Seam 显然非常适合作为 JSF 的补充，但是在激烈的竞争环境中，它遭到了一定程度的轻视。当今市场中充斥着各种各样的 Web 应用程序框架 —— 包括 Shale 和 Struts 2，新来者往往不受重视，Seam 还没有在主流行列站稳脚跟。 Seam 没有很快流行的另一个原因是关于这种框架的某些流言使 Java 开发人员没能认识到它的直接优点。

　　我要粉碎的一个流言是：Seam 只有和 EJB 3 一起使用时才有用，或者说在使用 Seam 开发应用程序时需要一个 EJB3 容器。实际上，Seam 的文档清楚地驳斥了这种误解："Seam 并不要求组件是 EJB，甚至在没有兼容 EJB 3.0 的容器时也能使用。" 如果说只有在使用 EJB 3 的同时才能使用 Seam，那么无异于说只有在使用 Hibernate 的同时才能使用 Spring。虽然这两对都有很强的互补性，但是每一对的两者之间都不是相互依赖的。

　　对 EJB3 的考虑

　　正如我将要解释的那样，Seam 通过一些有价值的 hook 和组件管理进程 扩展默认 JSF 生命周期。还可以完全独立于 EJB3 使用 Seam。但是要记住，和 EJB3 一样，Seam 依赖于 JDK 5 注释元数据进行组件声明，因此使用 Seam 时，还需要同时使用兼容 Java 5 的 JVM。图 1 显示了一个 Seam POJO 实现的应用程序堆栈：

图 1. 一个 Seam POJO 应用程序堆栈

　　实际上，即使完全不引用 EJB 3 jar 或描述符文件，也可以使用 Seam 的很多功能。当和 POJO 一起使用 Seam 时，该框架保留对组件实例化的完全控制，并且不要求任何专门的配置。Seam 负责大多数 Java 5 注释处理，而不需要依赖于 EJB 3 中的任何机制。的确 依赖于 EJB3 容器的一组有限的注释则是专用于那个环境的。在某些情况下，将 Seam 集成到一个没有 EJB 3 耦合的 IT 投资中可以获得更好的成本效益。如何使用 Seam 视个人偏好而定。

[1]  

【责编:Chuan】

--------------------next---------------------