CDI框架笔记-weld reference中文翻译（四）

请尊重成果，如需转载请注明来源http://equalxx.iteye.com/

 

题外话：啊= =好久没来更新了，之前一直有活，而且度过一个忙碌的春节。我敬爱的爷爷在今年走完了他82年的人生旅程。有时候真是要好好思考人生的意义了。体重来到这家公司后涨了十多斤，从少女一下变大妈了。。告诫大家少吃外卖，也别老觉得舔不干净盘子是浪费粮食了，少吃饭更健康啊，多运动，对，多运动。

 

2.1.2 Scope

一个bean的Scope决定了它的实例的生命周期和可见性。CDI上下文模型是可扩展的，可以用来容纳多种scope。一些重要的scope在规范中内置，并且由容器提供。每一个scope都有一个注解修饰。比如说，任何一个web应用都很可能会有session scoped bean：

public @SessionScoped

class ShoppingCart implements Serializable { ... }

 

一个被session scoped修饰的bean会被绑定到用户会话（user session），并且被所有在此会话的上下文中执行的请求共享。

注意：

注意一旦一个bean被绑定到上下文中，它会一直存在上下文中，直到这个上下文被销毁。没有任何手动方法可以从上下文中删除一个bean。如果你不想让bean一直停留在会话中，可以考虑使用生命周期短些的scope，类似request或conversation scope。

 

如果没有明确指定scope，那么bean会归属于一种特殊的scope，这种scope叫做dependent pseudo-scope。属于这种scope的bean只会存活并服务于在自己注入的对象，这意味着它们的生命周期取决于注入对象的生命周期。

 

我们会在Chapter 5 scopes and contexts中讨论更多有关scope的内容。

 

2.1.3. EL name

如果你想在支持EL表达式的非Java代码中引用bean（比如JSP或JSF），你必须得给bean添加一个EL name。

EL name通过@Named注解来定义，如下所示：

public @SessionScoped @Named("cart")

class ShoppingCart implements Serializable { ... }

 

现在我可以轻松地在JSF或JSP页面中使用它：

<h:dataTable value="#{cart.lineItems}" var="item">

...

</h:dataTable>

 

注意：

@Named注解不是用来指定这个类是不是bean的，大多类已经被作为bean来识别。这个@Named注解只用来EL引用bean，最常见就是JSF视图的调用。

 

我们可以不用在Named后面括号里写名称，让CDI自己来指定一个名字，像下面这样：

public @SessionScoped @Named

class ShoppingCart implements Serializable { ... }

 

默认起的名是首字母小写的非限定类名，在上面这个例子里就是shoppingCart。

 

2.1.4 Alternatives

我们已经知道了在开发阶段如何用qualifier区分同一接口的不同实现类。但是有的接口（或其他bean type）他们的实现需要取决于开发环境。比如说，我们可能需要在测试阶段使用一个模拟实现（不同于实际应用场景的实现）。这时可以在类上使用@Alternative注解。

 

public @Alternative

class MockPaymentProcessor extends PaymentProcessorImpl { ... }

 

我们通常在同一个接口有其他实现类的时候，在实现类上添加@Alternative注解。我们在部署阶段可以通过在jar包或是Java EE模块的META-INF/beans.xml中配置不同的替代实现。不同的部署场景下使用不同的替代方案。

 

我们会在第4.7章节 Alternatives进一步讲解。

 

2.1.5 Interceptor binding types  拦截器绑定类型

你应该比较熟悉在EJB 3中使用拦截器。JavaEE 6以来，这个功能已经可以被其他托管bean使用。也就是说，再也没必要为了一个拦截方法而去创建一个ejb了。那么CDI能在此之上提供什么功能呢？有很多，让我们先来介绍点背景知识。

 

在JavaEE 5中设计的拦截器是有点不科学的。会要求开发者直接在EJB的实现中通过@Interceptors注解或xml配置去实现拦截器。这样造成用户可能直接把拦截器代码放到实现类里了。第二，拦截器调用顺序取决于注解或xml描述中的声明顺序。可能这种方式对于单个bean还不算太糟糕。但是如果你反复使用拦截器，会发生对不同的bean有着不同的拦截器调用顺序。问题就来了。

 

CDI提供了间接层来把拦截器和bean绑定，并进行控制。我们必须定义一种绑定类型来描述一个拦截器的实现。

 

拦截器绑定类型是由用户通过@InterceptorBinding定义的注解。它可以使拦截器类简洁且无直接依赖地绑定到bean类上。

@InterceptorBinding

@Inherited

@Target( { TYPE, METHOD })

@Retention(RUNTIME)

public @interface Transactional {}

 

实现了事务管理的拦截器可以像下面这样声明：

public @Transactional @Interceptor

class TransactionInterceptor { ... }

 

我们可以通过在bean class上标注拦截器绑定类型来实现bean上的拦截：

public @SessionScoped @Transactional

class ShoppingCart implements Serializable { ... }

请注意ShoppingCart和TransactionInterceptor之间没有任何联系。

 

拦截器是部署时指定的。（我们在单元测试时不需要拦截器！）一个拦截器默认为不可用的。我们可以通过jar包或是Java EE 模块的CDI部署描述文件META-INF/bean.xml来使一个拦截器可用，这些文件也可以定义拦截器顺序。

 

我们会在Chapter 9 拦截器以及Chapter 10装饰器中讨论拦截器，以及它的兄弟装饰器。

请尊重成果，如需转载请注明来源http://equalxx.iteye.com/