seam in action 第一部分 1.3

最新推荐文章于 2025-08-09 11:07:38 发布

最新推荐文章于 2025-08-09 11:07:38 发布 · 146 阅读

文章标签：

#Seam #JSF #JPA #应用服务器 #Spring

seam 专栏收录该内容

7 篇文章

订阅专栏

本文探讨Seam框架如何简化JavaEE开发，通过整合JSF、JPA和POJO组件，解决传统技术间协同工作的难题。Seam通过统一组件管理、减少XML配置、使用注解等方式降低开发复杂度。

1.3 seam通向统一的方法
Seam通过结束Java EE平台的多样化以及统一它的组件、填补经常被批评的空白、使Java EE技术更易访问、将其触角延伸到第三方框架和类库、将这些技术很好的结合并使其具有一致性从而使Java EE重新焕发活力。尽管Seam的特性广范，但Seam的核心任务是让JSF，JPA和POJO组件能一起工作，使开发人员能把精力投入到构建应用上，而不是放到集成不相关的技术上

1.3.1 Seam将JSF，JPA和POJO组件融为一体

使不同技术之间协同工作不仅仅是在它们之间来回传递数据这点事，要创建使他们之间边界变得模糊的相互合作，使他们就像一个统一的整体。Seam通过使EJB3与web层相接、为JPA找到合适的位置、去除无效的JSF受管bean容器来实现Seam集成统一的目的。在检阅Seam是如何处理这些挑战性问题之后，你就趁机决定那个Seam堆栈适合你。

帮助在web方面受到挑战的EJB3

EJB在设计上有意使其组件不能直接绑定到JSF视图，因此EJB组件的可扩展性、事务性、线程安全和安全非常棒，但是如果将他们完全独立于web层，仅能通过JSF backing bean作为中间者访问，这样做的就不怎么好了。由于要想整合EJB会很复杂，所以这种隔离使他们在web应用有限。它们不能够访问任何web层范围(request,session,和application)或JSF组件树中存放的数据，因此削弱了它们对应用的非常重要部分的了解(Seam的目标就是真正让EJB3组件能够访问Seam有状态范围的数据)。而且，从web层使用EJB组件时候很容易在并发情况下带来麻烦。举例来说，Java规范并不要求Java EE容器必须实现对同一个有状态会话bean访问的序列化，而是把这个工作留给了开发人员来处理或者是捕获并发访问导致的异常。同样，当处理非线程安全的资源如JPA EntityManager的时候也会出现复杂情况。开发人员在web层安全的使用EJB组件的唯一方式就是通过一个适配器层进行交互。

Seam使EJB3组件能够访问web层范围的数据，提供了管理EJB3组件状态的一种方式，所有可以在web层安全的使用，甚至对并发访问有状态组件的序列化问题都交给了基础设施来负责而不是程序员。同时，seam中也不在有访问非线程安全的问题因为Seam恰当地处理了数据范围。

反过来，JSF同样面临访问业务层组件的挑战。
将JSF挂接到更好的后端组件

JSF有它自己的受管bean容器，与基于注解配置EJB3正好相反，它是通过冗长的XML描述文件来配置的，只有有限的依赖注入功能。尽管JSF受管bean可以保存到web层上下文中，但是他们是没有什么价值的对象，缺乏可扩展性、事务原子性以及安全性(可能这就是为什么它们被成为beans而不是组件的原因)。它们必须伸手够到EJB3组件以获得这些业务服务，这时你发现正陷入了创建连接EJB3组件和作用在他们上的UI的门面层的泥潭。

为了改正这个错误搭配，Seam使JSF UI组件直接利用EJB组件替代JSF“后端”beans和action监听器。从此也就不需要受管bean的门面层和冗余的XML描述符了。通过消除由于错误搭配引起的复杂性，促进了开发人员放宽了对过重的架构设计的严格要求。

你是那个Seam？

Seam不是扔到你桌子上不负责任的一些类和构件的集合。Seam成功的关键在于它提供了能够方便操作且经过良好测试的资源包。这些资源包包括许多第三方离开兼容版本。你可以把购买Mac的简单和购买Dell做个比喻。当你购买Dell时候，你可以定制组装，完全可以按照你的要求定制，但是你需要大量的思考并且要付出努力。相比之下，购买Mac更加简单，你在laptop和notebook之间选择，然后选择屏幕尺寸，剩下其他任何细节都有Apple为你做了。Seam有一组类似的选择集，你选择一个状态提供着和持久化提供者(继续选，一个web框架)，剩下其他任何的细节都由Seam开发者为你做。通过去除太多的选择负担，Seam可以使开发者的生活更加轻松。

图1.3总结了在Seam应用中两个主要技术的选择，就是状态提供者和持久化提供者。状态提供者是处理应用程序逻辑和响应UI中的事件的技术。持久化的提供者就是从持久化存储仓库存取数据。Seam管理持久化提供者，允许持久化上下文在跨越一系列页面而延续，并在多个组件之间共享。

前面已经提到过，Seam不要求必须使用EJB3。你可以选择使用JavaBeans和Hibernate而不用担心在功能上失去优势。从广义上术语JavaBean包括所有非EJB组件，所以Spring beans也可以看作是JavaBean。另一个流行的选择就是通过JPA与JavaBeans结合而部分的采用EJB3，这在本书的例子中就有。

Seam之前，让这些技术能一同使用就意味着要集成到管理他们的容器。EJB3有它自己的容器，JSF也有。Spring同样也是。同时，写这些粘合代码的任务就落到了开发人员身上。对中心集成点的需要促使了Seam上下文组件模型的诞生。

1.3.2上下文组件模型

Seam的核心就是上下文组件模型。在你往下看之前，说出三个你认为这个术语对你的意义的短句。(1)Seam是一个根据组件定义来构建对象的工厂。(2)在创建完后，每个对象都保存到基于不同生命周期的上下文的容器中，使对象能够上下文关联并且持有状态。(3)Seam促进了不同上下文的有状态对象之间的合作，根据对象各自类中的元信息将他们组装到一起。第四章深入研究了组件和上下文，你会有机会学习到在应用中如何使用它们。

在这部分，你将了解Seam模型是如何为前面所将技术的统一提供基础。通过组件注册、注解、配置例外(configuration by exception)、方法拦截器和统一表达式语言结合来促进统一。

一个中心组件登记处

Seam快速取得Java EE组件登记到注册中心，无论是EJB session beans，JavaBeans，Spring beans或者是JPA entities。任何集成到Seam堆栈的技术都可以指望Seam 容器根据组件名称取出组件实例并与容器协同工作来交互状态。可以访问容器的技术包括Seam 组件，JSF视图模板，Java Business Process Management process definitions，Drools rules，Spring beans，JavaScript以及更多技术。Seam容器统一了Servlet API的变量范围，同时引入了它自己的两个有状态范围，对话(conversation)和业务处理(business process)，使其更适合支持用户交互。

当然，不仅就是注册组件，它们也会被重新召集。Seam巡查类路径并列举任何包含有能够标识它们是组件的注解的类，马上讲到。

注解优于XML

Seam削减Java EE配置方式之一就是避免没有必要的XML。尽管曾经由于XML的灵活性被认为是可取的，但是XML是外部的配置文件，很快与应用程序逻辑不同步了(失去了控制)。Seam使配置文件和代码一致，并容易定位和重构。

当在将JSF受管bean要被定义到XML的时候，Seam说“不”，图1.4说明了Seam的原则。Seam将组件的声明变为单个注释@name，放在class定义之上。Seam组件可以替代JSF受管beans。

如果你足够投入的话，在Seam你中你可以完全不使用XML，这对于一些地方有必要使用它的地方而可以不用肯定会让人大吃一惊。Seam只是在注释不能满足需求的时候或者在隔离可覆盖的配置文件的时候才用MXL。如果你不喜欢注释，那么你也可以不用注释，Seam仍然可以让你使用XML定义组件，这是第五章的主题。我个人而言，注释更简明更容易维护。

从XML转到使用注解不只是提升了敲击键盘的效率，它还是Seam的配置特例策略的核心部分，只有真正需要XML时候才使用它。

配置例外(CONFIGURATION BY EXCEPTION)

说软件是“有主见的”，这是解释配置例外一个好方式。通常的观念就是：框架更愿意按照它所被设计的那样去操作。你使用默认的东西的越多，你所需要做的工作就越少。只有当软件需要做一些与典型行为不同工作的时候才需要你介入并发挥你的作用。

在Seam中，配置例外与注解紧密合作。注解给Seam一个所使用的行为暗示，然后Seam依靠合理的默认和标准的命名规范尽可能猜测这个声明的含义以减轻你的工作负担。通过这种方式，Seam在显式的声明和推测功能之间实现了很好的平衡。

注解减少了敲击键盘次数，消除了XML。不仅如此，注释提供了类定义的附加元信息，这比把元信息存贮在外部文件中更容易找到和重构。

使用服务进行装饰

因为是通过Seam容器来请求组件，Seam有机会来管理组件的整个生命周期。Seam使用拦截器装配对象，在将新创建的实例往下传递之前，把其包装到一个称为代理对象的外壳中。这让Seam充当了操作木偶的人，在每个方法调用的时候添加其行为，像图1.5描述的样子。拦截器负责使Seam能够正常工作的许多隐含逻辑，例如，开始事务和提交事务、强制实施安全以及使对象与其他对象关联。如果处于某些原因，拦截器不能使用或者需要与默认行为不同，那么在类定义上的注解会给它一个如何应用附加功能的暗示。