seam in action 第一部分 1.3

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能够正常工作的许多隐含逻辑，例如，开始事务和提交事务、强制实施安全以及使对象与其他对象关联。如果处于某些原因，拦截器不能使用或者需要与默认行为不同，那么在类定义上的注解会给它一个如何应用附加功能的暗示。

 

 

最后一部分难以统一的就是能够为应用提供一种通用的语法来访问容器中的组件。这就是统一表达式语言的作用。

延伸统一表达式触及的范围

统一表达式语言是一个用于解决变量以及将组件绑定到JavaBeans的属性、方法的可描述性的语法。它首次被引入是为了改善JSF与JSP整合、为了查询存储在web层的受管bean和其他对象，并作为JSF绑定机制的基础。然而它的影响非常广范，这多谢其可插拔的设计。

EL是一个开放的API，允许注册自定义的resolver，这使EL变为一个变化的集线器，任何层的代码要想利用EL统一变量上下文都可以使用开放API。EL使你免去在由不同技术所使用的变量上下文和你的应用之间要开发自定义连接桥的负担。尽管你曾经只是在视图层看到用过它，但实际上它与web一点都不相关。

Seam以两者方法来使用EL。首先，Seam注册了一个能够感知Seam container的自定义EL resolver。在应用中任何可以使用EL表达式的地方(

继上文（发了n遍，还是没发全，估计是字数限制）
几乎是任何地方)都可以通过EL notaion访问Seam组件。第二，Seam背地里使用了大量EL，并允许在注解、配置文件、日志和消息字符串、JPQL查询语句、页面流定义、甚至business processes中使用EL。有了Seam，EL真正的被统一了。
尽管所说的都是关于Seam的事情，但还没有谈及任何程序员所喜欢的代码。为了证明Seam为什么是一个好的选择以及它是如何节省你宝贵的开发时间，我现就用一个简单的例子刺激以下你的胃口。在第二章，你会有机会一些命令来构建一个完整应用而深入了解Seam。

强烈支持楼主

只想请问一下楼主，你实际项目中用过吗？我们最近项目就是基于SEAM的，很多东西用了才会知道，component的方式理论上重复利用率高，实际开发起来，问题多多，
1，SEAM记录了大量的状态，所以每次请求都将会和服务器交复很多数据，我没有实际测过，我们组成员人人测过，据说可以到达4M，想想吧4MB多么恐怖
2，新加的作用域conversation，再加上@Begin 注解，很多问题就来了，经常会出现，你认为某个对象应该存在，而它却不存在，而你认为他不存在，他却存在，试想一下conversation 的@Begin标注的方法，都会自动提升为lang-running conversation,要是你的重复的点某个地方（重复发送请求），会产生重复的无数 个conversation再加上converation里的一些组件，你很自信你的服务器能抗下来。
3，JPA还相当不成熟，很多东西不支持，给你们来个实际的例子吧。。
页面展示需要做两次查询的组合，起初是在一个方法里面做两次不同SQL查询，然后添到一个List 里返出来，但是现在要分页，什么有人说用unio，对不起不支持，
4，用seam必然就会提到ajax，好A4J 标签出场了。。。慢慢来，问题多多多，

 

     没有seam的实际项目经验，但是比较喜欢seam的简洁（相对而言），比起以前学习spring感觉舒服多了。目前研究seam主要是学习它的思想、编程实践，从中摄取营养。
     对于你说的几个问题，我想谈下自己的个人看法：
1.多少用户情况下是4M？几万？几十万？几百万？ 光谈及这个4M并不能说明啥问题，对服务器不会造成任何影响。我认为更重要的是要看在随着用户数量的增多，这些在服务器端保存的数据量是不是以线性增长甚至是指数增长，增长的幅度是否是可以接受的，根据实际情况采取相应措施。
2.新加的作用域conversation，再加上@Begin 注解，很多问题就来了，经常会出现，你认为某个对象应该存在，而它却不存在，而你认为他不存在，他却存在

   这是你的问题还是seam的问题？试想一下conversation 的@Begin标注的方法，都会自动提升为lang-running conversation,要是你的重复的点某个地方（重复发送请求），会产生重复的无数 个conversation再加上converation里的一些组件，你很自信你的服务器能抗下来  不会这样把，有些记不清了，应该是在执行标有@Begin的方法时候才会产生一个长时间的会话，而且这个会话是比session失效时间要短的，你可以根据实际情况设置，seam帮你清除（要是以前你的自己确保清除），只要seam没内存泄露，那么对于你服务器没问题的。而且我想你也不会用seam开放sns应用吧。

3.你完全可以使用hibernate，它提供了一些JPA没有的功能扩展（每用过，没更多的发言权，呵呵）

4.seam表现层可选的技术比较多，而且你使用什么技术都会遇到问题的，不要指望使用那个技术可以完全让你不用操心费力。而且这个也跟seam没啥关系啊，seam做的就是集成各种技术，省去你自己集成、自己管理这些状态等等。

个人认为seam在企业级开放方面还是比较有作为的，但学习seam的成本可能会高些，涉及的技术比较多，比较难，这是正常的，因为它解决的就是企业级开发中的难题，事务、安全、多线程、分布式等等。它相对应以前你自己集成ejb,jsf,hibernate已经轻松多了，你需要考虑的、需要做的事情以及大大简化了，虽然是简化了但你不要指望在使用它时候不会带来任何的问题。在开始使用新技术的时候都会遇到种种问题，但是你为什么还会使用它？因为它是未来发展的方向，它解决了一些你日常开发中重复出现的问题。

     最后，还是那句话，任何技术不可能没有缺陷，不可能是拿来主义，在你没有熟练掌握它之前、在它没有成熟之前更是不可能的！