Spring 和EJB终于统一融合

08-09-20 banq
                   

Spring 和EJB争吵终于即将结束:Spring将支持EJB3.1标准,Spring will also be a full featured EJB 3.1 implementation for use in the WebLogic application server.这场融合将在javaEE 6实现,这个融合和当初Hibernate与JPA融合一样水到渠成。

Spring创始人Rod Johnson 说Spring 2.5的dependency injection annotations是学习得益于EJB 3.0的 @Resource 和 Google's Guice,我不知道他为什么没有提picocontainer,至少他的Spring 2.5开始直接大胆使用DI的auto wiring(而这个功能在Spring 1.X中还是可选功能),而2005年我的Jdon框架就完全是auto wiring。

Rod Johnson 鼓励开发者使用EJB标准,比如 @PostConstruct 和 @PreDestroy annotations,因为他们是标准化的,Spring已经支持他们(Spring才支持它们?今天才明白?),这些都意味着Spring和EJB争吵的结束。

其实EJB的@PostConstruct @PreDestroy @Resource 这样annotations都可以在EJB2中找到影子和原根,表现语法不一样,但是内部机制原理是一致的。所以,以前没有学过EJB的,看来还是要补这一课。

PostConstruct和PreDestroy都是在对象生命周期开始以及结束让程序员能够进行一些状态管理,比如开始一些场景准备和加载,或者结束后,释放一些资源,防止内存泄漏,这些都是从EJB1.X 无态Bean开始就有的功能,不过当初是使用XML配置,并且无论程序员实现与否,一定要写这几个方法,现在通过注解 annotation 加在你需要实现的方法上,更加简洁方便。

所以,我以前说:如果说EJB1/EJB2X是一个定型的女孩的话;那么EJB3引入IOC/DI依赖注射和annotation以后,就更漂亮,更加吸引程序员接近她,也非常容易和其打交道了。

EJB从开始诞生起,因为高低各种原因,被高端和低端各种人怀疑打击,真正是遭受了不公平待遇,

高端专家比如Martin Fowler因为其不宜测试,提出POJO思想,认为对象应该不依赖平台,应该是一个个光溜溜来去无牵挂的,不继承任何框架接口等。不可否认POJO促进了EJB3变得更漂亮,但是EJB内在分布式计算组件的重点没有变。

在低端程序员中,EJB以其深奥的原理和超前的设计思维,更不能被他们理解,他们甚至以一种僵化思维来看:现实80%不是大系统,不需要集群分布式计算。

他们这种思维去炒股票肯定输得血本无归,因为,他根据他看到的80%股票下跌,20%上涨,因此决定自己是进入80%的股票还是进入20%股票,这种以过去经验的僵化思维来决定未来的策略和“守株待兔”没有区别,今天看到一只兔子撞死在树下,明天就在这里等,以为同样事情发生。

你今天做的系统在以后几年可能不需要集群,不需要对付大访问量,但是你能保证你做的每个系统都是这样,你为什么要等这个系统真的可能被某个风险资本看中,发展为全国系统,抗不住大访问量时,再去救它吗?为什么不在当初系统架构设计时,以较小的代价设计一个可伸缩的 有预先的系统呢?

我一直主张“数据库已死”,因为正如Hibernate创始人Gavin King说说:数据库是最不具有伸缩性的,不具伸缩,就是没有弹性,就是阻碍我们将整个系统设计成可伸缩 灵活系统的绊脚石,这样技术不宣布其死刑,又能如何呢?

我宣扬的这些思想是一个很高很深刻的架构思维,就像我们追求设计模式,因为软件不是将功能做好就够了,要考虑将来维护拓展时的方便,好不容易不少人接受模式,但是他们更多不知道为什么要使用模式。否则,他们就不会那么不理解“数据库好好的,为什么让它死,没用吗?”

所以,从Spring和EJB争论,以及最早的EJB CMP和Hibernate争论中,都可以看出国内大多数程序员盲目跟风,没有自己思维和观点的特点。

现在我们追求领域建模,认为数据表创建只是程序部署运行时实现的,而不是在程序编写之前或编写时创建的,EJB CMP最早提供了模型自动创建数据表的功能,但是大多数人只看到EJB这样一个超前产品的缺点,包括Gavin King本人,但是自从他进入EJB 3.0专家组以及他对EJB的逐步了解,他已经是EJB的拥护者,并推出基于JSF+EJB3的框架Seam。

我一直也奇怪,为什么EJB这样超前标准得不到大多数程序员的理解,不是EJB太高,而是我们程序员太弱,在面向对象上是空白,在分布式计算上更是幼稚。

对于那些盲从Spring的拥护者来说,原来他们说有了Spring就足够,不需要学习EJB,现在Spring 2.5新增的这些注解,同样他们付出学习EJB一样的精力,在我们程序员中,对对象生命周期 状态管理等极其薄弱,

因为面向过程背景的限制,变量函数在运行时情况是统一一致的,而java中一个类在运行是可以有多个实例,也可以有一个实例,每个实例能够存活多长时间,从什么时候开始创建诞生,如何能够被垃圾回收机制顺利回收,结束自己的生命周期,这些都掌握不到位。

从Spring和EJB这场争论中,从名义上看,是EJB标准取得了最终胜利,但是,也正是Spring和Hibernate的竞争,促进了EJB走向完美。Rod Johnson也从当初狂喊"J2EE without ejb"的大忽悠,转变到现在鼓励大家使用EJB标准,因为他明白了,可是他那些盲从者不知明白了没有。

没有明白的就开始嚼嘴皮子了,玩语言游戏:EJB3还是按照Spring写的标准呢?这完全是一厢情愿的想法:上面谈的Spring 2.5那些@PostConstruct注解早就在EJB3.0里就有,EJB3.0是先于Spring推出Annotation的,EJB内在的有态对象管理自从EJB1.X就有,Seam更是将EJB推向应用高峰。我们从Jboss Seam的受欢迎程度已经可见一斑,现在找工作,不懂SEAM恐怕就象当初不懂Spring一样不时髦。

本人Jdon框架从一开始也提供了Session有态管理,当时我也在J道指出了Spring1.x无状态管理的缺点,虽然Spring2以后开始提供scope="session",但是到现在2.5版本才提供缺省的依赖注射自动配对,可见Spring2以后版本在某些方面似乎在“补课”。

如果说Spring对EJB3有所促进的话,就是其依赖注射IOC/AOP设计思想。由于和AOP冠军ApectJ融合,致使其在AOP方面的强大是首屈一指的。可惜实践中我们发现,语言级别的AOP才可能是我真正需要的,我需要修改运行中对象的属性和方法,这些如果JVM能够提供将是一个跃进。

所以,无论是Spring向EJB汇合,还是EJB向Spring汇合,这些都已经不重要,因为他们已经不再分裂,而是一个统一名称EJB。从Spring诞生引起的潮动到今天与EJB合一的解释以及Seam的热捧等这一系列事件中,可以看出:如果我们程序员自己不具备深刻的OO思维,不具备高度的架构思想,不具备专业的软件设计思想,面对国外瞬息万变的各种思潮,就只能发生盲目崇洋,盲目跟风,甚至东施效颦。

End of Spring vs EJB wars in sight?

http://www.ryandelaplante.com/rdelaplante/entry/end_of_spring_vs_ejb

本站以前Spring与EJB讨论:

关于SPING与EJB的胡言乱语--重和轻永恒的话题

http://www.jdon.com/article/24513.html

探讨Spring框架使用真相

http://www.jdon.com/AOPdesign/spring2.htm

转贴:Spring vs EJB

http://www.jdon.com/article/18904.html

EJB3与EJB2架构对比

http://www.jdon.com/artichect/EJB2_EJB3.html

项目规模的界定!

http://www.jdon.com/jivejdon/thread/17993.html

可伸缩性和重/轻量,谁是实用系统的架构主选?

http://www.jdon.com/jivejdon/thread/15634.html

EJB2.x已死

http://www.jdon.com/jivejdon/thread/17995.html

Why “J2EE Without EJB”?

http://www.jdon.com/jivejdon/thread/16699.html

[该贴被admin于2008-09-25 08:25修改过]

                   

1
freebox
2008-09-21 05:14

spring在之前也能通过实现接口管理生命周期,现在改成注释形式方便了。没有状态的对象也只适合当服务,一个就够了。

另外2.5的那几个@Component、@Repository之类的注释还是太弱了,我们改造了一个实现做了个@Factory,同时也在期待spring在这几个注释方面的加工。

fox0424
2008-09-21 09:27

EJB是必然之路,spring想从中小企业开发的模式中走出来,就必然要向着EJB的方向发展。

不过不喜欢注释这样的东西,觉得它破坏了程序的优雅性,虽然便捷,但具有很强的绑定性。

freebox
2008-09-21 17:15

注释的确不应该放在业务类里,严重耦合技术成分,XDoclet也不是很好,加了一些影响注释说明的附加技术内容。

我们的做法是在开发阶段用jdk1.5注释并加上FIXME注释,减少大脑在配置和代码间的切换,在上架前再根据FIXME统统改进xml里。

javaejb
2008-12-07 16:25

感觉banq老师的EJB技术真是太高了。非常佩服。

2Go 1 2 下一页