CDI是什么?

10-03-24 banq
CDI(Contexts And Dependency Injection)是JavaEE 6标准中一个规范,将依赖注入IOC/DI上升到容器级别, 它提供了Java EE平台上服务注入的组件管理核心,简化应该是CDI的目标,让一切都可以被注解被注入。

Contexts概念和我们之前在DCI架构中讨论的业务场景不一样,包含有容器技术架构场景的意思,场景包括四种:request (event), session, application, page,而SEAM框架拓展了两个 conversation 和 business process context。

CDI对JSF和EJB模型使用都产生比较大的变化,比如对JSF影响,下面是JSF的一个用来显示的Bean:

import javax.inject.Named;

@Named
public class MessageServerBean {

    public String getMessage() {
        return "Hello World!";
    }
}
<p>

使用了@Named来标注,那么在jsp页面中就可以写入标签:

       Message is : #{messageServerBean.message}<br>
        Message Server Bean is : #{messageServerBean}
<p>

达到输出如下结果

Message is : Hello World!
Message Server Bean is : eedemo.MessageServerBean@xxxxxxx
<p>

也就是说,@Named标注实际相当于给MessageServerBean取名eedemo.MessageServerBean(当然你也可以显式写一个名称),你就可以直接以messageServerBean对其getter方法进行输出了。

CDI另外一个特点就是将对象在容器中场景生命周期标注出来,如下:

@Named("itemProcessor")
@RequestScoped  //表示生命周期是request,每次request请求结束,生命就终止,也可以有Session或 Application等
public class ItemProcessor {

    @Inject
    private ItemDao itemDao; //表示ItemDao需要被注入

    ...
}
<p>

大家已经看见,其实这些招已经在Spring或我们的Jdonframework中普遍使用,实际是依赖注入的升级版。是一种自动配对auto-wired的注入,不是Spring 1.x中那种手工配置依赖的那种。我在05年文章Ioc容器的革命性优点就提出自动注入划时代的意义。曾经有一段时间还把这作为jdonframework和Spring 1.x区别吹嘘很长时间,现在都已经是平常事了。

CDI还提供了Producer方法,也就是工厂方法的实现,这样在这个对象被注入之前,你可以定制一些你自己的东西。

public class PersonFactory {

  @Produces 
  @RequestScoped 
  public Person createPerson() {
     return new Person();
  }
}
<p>

但Person被注入到其他需要Person的地方之前,createPerson首先被执行,在这个方法中你能做一些注入之前的准备工作。

CDI还提供Events事件注入,使得异步事件模式能够引入JavaEE中。

事件消息分生产者和消费者,见 Event-Listerner事件监听模式一文。消息生产者定义一个事件:

@Inject

private javax.enterprise.event.Event<User> userEvent;

激活一个事件是:

userEvent.fire(user);

消息监听者也就是消费者,只要标注@Observes ,即可处理发出的事件:

public void observeUserEvent(@Observes User user) {
 ...
}
<p>

事件模式的引入可以为我们实现业务场景融合提供手段,见ZK的CDI应用

@Named
@SessionScoped
public class HelloWorld extends GenericComposer implements Serializable {
 
	@Inject @ComponentId("guestName") Textbox guestName;
	@Inject @ComponentId("sayHelloBtn") Button sayHelloBtn;
	@Inject @ComponentId("helloWindow") Window helloWindow;
 
	public void sayHello(@Observes @Events("sayHelloBtn.onClick") MouseEvent evt) {
		helloWindow.setTitle("Hello " + guestName.getValue());
	}
}

<p>

不过,这个事件模式和Jdonframework提供的基于领域模型的Domain Events比较类似,但还是有些区别,目前看来,CDI这种事件模式还是组件(userEvent)驱动领域模型(user),不同于JF是领域模型自身发出事件,这两者还是有本质区别,更加突出领域模型作为业务核心的重要位置,而JavaEE6为了强调其技术架构的重要位置,免不了和业务争夺核心位置,这是我们使用者必须注意的,不能死读标准。

CDI还提供了@Decorator和@Interceptor,这涉及AOP和动态组件的概念。有兴趣可仔细研究。

相关资料:

JavaEE6和CDI

From JBoss Seam to CDI (JEE6)

JavaEE 6:EJB3.1新特性

[该贴被banq于2010-03-24 11:41修改过]

13
joshuayan
2010-03-24 12:54
cdi必须依赖支持符合JAVAEE6规范的容器,感觉不那么容易使用

banq
2010-03-24 13:53
2010年03月24日 12:54 "joshuayan"的内容
cdi必须依赖支持符合JAVAEE6规范的容器,感觉不那么容易使用 ...

JavaEE6服务器今年陆续上市, GlassFish 3已经支持,JBoss估计到年中,其实SEAM框架已经主导了JavaEE 6标准。SEAM和GLASSFISH组成联盟了。

至此,Spring和JavaEE终于分道扬镳了,Spring也在发展自己的服务器,企业Java未来变得清晰了:FUTURE OF ENTERPRISE JAVA ...IS CLEAR (JAVA EE WITH/WITHOUT SPRING AND VICE VERSA)

对于实际项目,你得签署两份维护和支持合同,一份是应用服务器,一份是SpringSource. 这实际是让企业用户为难,最后就形成两种结果:

1.部署Spring在其自己的服务器上

2.部署没有Spring的Java EE 6应用(you could build them with Spring support, but deployment to production will be the issue)

The future of Enterprise Java is very clear - full stack Spring or full stack Java EE - but no mix any more.两者再也不会搞在一起了。

在另外一篇文章:LEAN JAVA EE 6 WITHOUT SPRING AND SPRING 3.0 IN JAVA EE 6 WORLD: SUMMARY AND CONCLUSION (EJUG SESSION)

中对JavaEE 6和Spring 3进行了比较,认为Spring不是“约定优于配置”,很多事情都需要声明。Spring 3已经完整支持Java EE 6标准,除了@Stateless。

[该贴被banq于2010-03-25 20:29修改过]

xmuzyu
2010-03-24 23:09
呵呵,总之,觉得做软件得有自己思考,不能跟风,比如过去跟风EJB,现在都是Spring,以后不知道又要跟啥风呵呵。还是秉承jdon的风格,坚持以业务为核心,以业务驱动技术的思想比较切合实际一点。技术just a tool,业务 is the king.

joshuayan
2010-03-25 10:17
2010年03月24日 23:09 "xmuzyu"的内容
还是秉承jdon的风格,坚持以业务为核心,以业务驱动技术的思想比较切合实际一点。技术just a tool,业务 is the king. ...

完全同意

为了砍柴,我们也需要好好的磨磨板斧阿 :)

lendo
2010-03-25 18:25
最近做一私活,鬼子做好了架构,核心为Seasar,和Spring,JF很类似的一个框架,只不过比起Spring,JF,它要弱得多,虽然以前在国内就没听说过,也没用过,但很快还是搞定了它。技术仅仅是技术,做过几年代码有点点做代码的意识的人都可以很快学会它那框架。业务才是核心。

BTW:我看到Banq的代码里有标注,我不得不个人再鄙视一下Annotations,不论Banq是否同意,我只想表达我的观点,我觉得用了这玩意代码看起来真的是杂乱无章,我理不清调用的先后顺序,我也找不到接口的实现在哪,而且如果还有自定义的Annotaions,它在做什么动作只有写它的人才清楚了,用Annotations对于没有文档的遗留项目,我觉得它就是一噩梦,XML配置烦吗?我觉得EJB2.0的配置很优美呢,Fucking Annotations。

banq
2010-03-25 20:24
2010年03月25日 18:25 "lendo"的内容
,我不得不个人再鄙视一下Annotations,不论Banq是否同意 ...

比较理解你,初期我也是这样,不过后来随着设计要求提高,Java中也没什么东西可供使唤了,将就着用注解,发现能解决一些问题,不过千万不能过,Annotations至少不能超过Java的代码吧。

>比如过去跟风EJB,现在都是Spring,以后不知道又要跟啥风

现在是NoSQL和云计算,这些技术都是在颠覆JavaEE 或Spring。

借用Johnson在Java EE 6,貌似民主下的虚伪公平一句话:

“到另一个Java EE版本发布的时候,Java的应用情景和现在将有很大的不同,目前还倾向于利用数据库实现大部分应用程序功能,以后我们将看到更多不同的数据存储和不断增多的云部署,我们面临的再也不是这10多年来已经非常熟悉的问题,而是要开启新的篇章。”

现在JavaEE或Spring都倾向于利用关系数据库实现大部分应用程序功能,他们都倾向于保证高一致性,通过JTA事务,JTA或JDBC事务是EJB JPA Hibernate Spring的核心,而这种事务都是借助关系数据库的ACID完成的,在CAP定理中我们讨论了关系数据库ACID只能满足高一致性和容错性,丧失了性能可用性,特别是2PC,跨数据库的两段事务是性能杀手,这也是NoSQL总结分类中谈到。

所以,如果我们把这些都联系起来后,就发现技术发展清晰脉络。企业Java未来是变得清晰了,不再依赖关系数据库,而是根据企业业务应用灵活选择架构,高一致性不再是企业Java固定不变的准则,社会媒体已经渗透到企业IT和营销,企业Java也不再是落后技术的代名词。

[该贴被banq于2010-03-25 20:37修改过]

xmuzyu
2010-03-25 22:35
2010年03月25日 20:24 "banq"的内容
现在JavaEE或Spring都倾向于利用关系数据库实现大部分应用程序功能,他们都倾向于保证高一致性,通过JTA事务,JTA或JDBC事务是EJB JPA Hibernate Spring的核心,而这种事务都是借助关系数据库的ACID完成的 ...

如果完全遵照JEE规范来做企业级应用是没问题的,毕竟企业级应用对数据安全,完整性要求严格,而互联网应用,性能,伸缩性才是王道。因此互联网应用对性能和伸缩性的追求已经使得当当靠JEE规范是无法满足的。就如banq老师说的事务,JEE规范对事务的支持是非常好的,但是要想做一个可伸缩性的JEE的web2.0应用,还需要下很大功夫,还得学会折中,学会取舍。一个系统架构的过程,就是不断取舍,不断折中的过程。

banq
2010-03-26 08:15
2010年03月25日 22:35 "xmuzyu"的内容
一个系统架构的过程,就是不断取舍,不断折中的过程 ...

是的,正如Rod所说:以后我们将看到更多不同的数据存储(NoSQL)和不断增多的云部署(云架构 云部署),我们面临的再也不是这10多年来已经非常熟悉的问题,而是要开启新的篇章!

lendo
2010-03-26 10:20
2010年03月26日 08:15 "banq"的内容
我们面临的再也不是这10多年来已经非常熟悉的问题,而是要开启新的篇章! ...

Banq,你了不了解腾讯是如何处理几亿用户的数据的?他们都用到了哪些存储技术。如何处理数据大并发和数据同步的。我特别想了解了解。

banq
2010-03-26 20:31
2010年03月26日 10:20 "lendo"的内容
你了不了解腾讯是如何处理几亿用户的数据的 ...

不太了解,我个人觉得腾讯的处理要比facebook twitter这样Social media要简单,完全采取单纯的划分服务器,腾讯不能算真正社会媒体应用,需要向社会媒体模式转换,由于不在本话题就不多说了。

mellon
2010-03-28 18:29
啥也不想说,从去年12月10日那天,开始感到有点高兴了。

banq
2010-03-29 11:42
CDI实际是在弥补Web与EJB在生命周期上的鸿沟,昨天 What’s so wrong with EJB’s?讨论这点。

Web的生命周期是request session和application,CDI可以将这些使用@注解标注到EJB上,而EJB有自己生命周期类型:有态Bean,无态Bean和Singleton,比如SLSB是POOL支持,POOL本身就是一种生命周期,所以,这两者就矛盾了。题外话:在jdonframework中Pool和Session和Singleton是并列的,不可能同时存在,而JavaEE6引入CDI以后,因为历史原因,在生命周期管理上出现矛盾了,真是有些尴尬啊。

JSF的可管理Bean的生命周期能够绑定到request, session or application等场景上. 如果Bean中再调用EJB,而EJB有Stateless, Stateful or Singleton三种,那么使用开发者就自己动脑筋如何把Bean生命周期与EJB生命周期联系起来考虑,很头疼哦。有点类似对象和关系数据库的阻抗问题,我们在持久层做这种匹配事情,到前面表现层也要做,事情越搞越复杂,这样的JavaEE不要也罢啊。

lifecycle mismatch和Object relation mismatch已经成为JavaEE面对两大致命杀手。

[该贴被banq于2010-03-29 11:45修改过]

tangshd
2010-04-09 09:26
lendo

我和你一起Fuck Annotations

过后,还是要操起Annotations ..

是噩梦, 但是有时又离不开

[该贴被tangshd于2010-04-09 09:27修改过]

labchy
2010-04-10 20:38
学习一下

猜你喜欢
2Go 1 2 下一页