做为职业技能需求，Spring超过EJB了吗？

作者 Floyd Marinescu 译者 王丽娟 发布于 2008年2月21日 上午3时59分

社区

Java

主题

开放源代码,

JCP标准

标签

趋势,

EJB,

Spring框架

Rod Johnson将Indeed.com（一个求职网站）职位列表中对EJB和Spring两种技能的需求数量进行了对比，并通过分析这一统计数据得出了一些关于EJB的发展过程及其未来的结论。他围绕着会话Bean和消息Bean对EJB展开了讨论，并承认JPA做为独立的规范是有价值的，JPA“是基于现代技术并已开始体现其价值”。首先，Johnson阐述了职位要求所体现的趋势的重要性：

职位列表是技术真正被采纳的良好指示器。它们表明公司是否把钱花在了“刀刃”上；它们为开发人员指明获取、增强相关技能的重要性（这是技术延续的一个重要因素）；它们还为公司稳妥地采用特定技术提供了良好的指导。

随后，Johnson介绍了下面这个图表。该图表显示，截止到2007年11月，Java职位列表对Spring技能的需求已经超越了EJB。他认为倘若现在基于EJB的应用数量仍相当可观的话，那是很令人惊诧的。

Johnson评论这些趋势的时候有些洋洋自得，因为他2003年以来就预言EJB会因他在J2EE without EJB一书中描述的那些缺点而失去其实用性。甚至在他看来，EJB3.0新的改进也不足以遏制这种趋势：

EJB 3.0改进了一些事情，但还是太少、太迟：依赖注入（DI）的能力不足以满足实际需要；拦截API认识到了需要有一个对横切关注点的解决方案，但我们看到的还是一个最差、最笨重、最容易出错的解决方案（我一直想在博客上发布的一些东西）；由于要兼容那些现在已不相关的旧有技术，把它拖累了；沉重的EJB契约（它比“简化的编程模型”多出数百页）需要一个相当复杂的运行时环境，而且开销很大；尽管有语法糖（syntax sugar），但它还是不能掩盖EJB的大量缺陷，例如启动行为、单例、以及废弃的线程模型。最后，每次改变基础环境的时候，它都要有效地绑定到一个应用服务器环境中去。

接下来，他解释了对整个行业及开发人员个体来说，EJB的衰落意味着什么：

• 这不是反对标准——而仅仅是有选择性地反对那些无实际意义的标准。正如我长期以来一直指出的那样，Java EE不只是EJB，任何关心这个平台的人都应该真诚地对待其各部分的质量和关联性。
• 随着越来越先进的技术，业务对象变成了POJOs，对特殊组件模型的依赖在减少，标记也变得不那么重要了。
• 抛弃EJB后会有更好的架构灵活性来应对需求的变化。随着SOA和其它力量的兴起，公司也越来越多地选择轻量级的部署平台。

Johnson总结到：“由于其绝对数量仍然相当多，EJB不会很快消失。但是趋势曲线清楚地表明它正在逐渐成为过去”。EJB怀疑论者Rick Hightower也相信EJB仍然会存在一段时间。同时，他还表现出对这种对比方式的关注：

然而，EJB被废弃还是比较遥远的事情，难道不是吗？把Spring这样的通用架构（比如Spring MVC、Spring WebFlow、Spring XXX）和EJB这样有侧重点的框架放在一起做比较真的公平吗？正如从EJB3、Seam和Spring的比较图中看到的一样，对现有的开发人员来说，这种相对比较的方式是很不公平的。

Ray Van Eperen also commented in regards to the need to consider the possible impact of other technologies:

……对于象Seam这样的技术显然有一些疏漏，但Seam结合了EJB 3.0，它也弥补了很多EJB模型原有的缺点，也提供了许多与Spring一样的优点（使用POJOs和IOC等）。依我愚见，它要比Spring更好一些（比如说，它几乎完全基于注释，而不是XML）。我不是想打击Spring，我只是想说结合了Seam和其它技术（像JSF）的EJB3提供了一个非常可行的Spring的替代方法。

假如基于EJB的那些应用中有相当一部分内容是依赖于应用服务器的，而应用服务器恰恰是采用EJB规范专有的实现，那么在一些为它们的核心Java企业组件模型权衡开源框架的公司中，这些趋势会增加他们的信心。这些对比在表明Spring框架正在走向胜利的同时，不也恰恰表明EJB模型即将开始失去其实用性了吗？

查看英文原文：Spring Overtakes EJB as a Skills Requirement?

1. 返回顶部

   似乎忘记seam和spring的比较了

   2008年2月26日 上午4时52分 发表人 firefly sen

   我看到过一份spring和seam的比较。

   回复

• 更早的 >