CDI框架笔记-weld reference中文翻译(四)

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

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

2.1.2 Scope

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

public @SessionScoped

class ShoppingCart implements Serializable { ... }

 

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

注意:

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

 

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

 

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

 

2.1.3. EL name

如果你想在支持EL表达式的非Java代码中引用bean(比如JSPJSF),你必须得给bean添加一个EL name

EL name通过@Named注解来定义,如下所示:

public @SessionScoped @Named("cart")

class ShoppingCart implements Serializable { ... }

 

现在我可以轻松地在JSFJSP页面中使用它:

<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 { ... }

请注意ShoppingCartTransactionInterceptor之间没有任何联系。

 

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

 

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

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

猜你喜欢

转载自equalxx.iteye.com/blog/2367578