Spring 和EJB终于统一融合（转）

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思维，不具备高度的架构思想，不具备专业的软件设计思想，面对国外瞬息万变的各种思潮，就只能发生盲目崇洋，盲目跟风，甚至东施效颦。