领先一步
VMware 提供培训和认证,助您加速进步。
了解更多职位列表是技术真正普及情况的良好指标。它们表明公司是否在花钱,从而区分实质与炒作;它们表明开发人员掌握和发展相关技能的重要性(技术延续的一个重要因素);它们还可以为公司采纳特定技术的可行性提供良好指导。
因此,职位列表聚合网站 Indeed.com 的 jobtrends 网站是一个重要资源。它允许跟踪职位要求数量随时间的变化趋势,并方便地比较技术。
有时这些趋势会带来巨大的影响。Indeed.com 显示,在 2007 年 11 月,Spring 在 Java 职位列表中的技能要求超越了 EJB。截至昨天,Spring 的职位数量为 5710 个,而 EJB 为 5030 个。
通过比较绝对职位数量,我们可以看到趋势线以及它们何时交叉
考虑到大量的遗留 EJB,这真是令人惊讶。推测起来,现在很少有新项目使用 EJB 了。
“相对”图表,比较各自的增长率,则更有趣,它显示了这两种技术之间鲜明的对比
我们看到 EJB 的需求停滞不前或呈下降趋势,而 Spring 的需求正以不断增长的速度增长。
当然,Spring 和 EJB 并非互斥。使用 Spring 并不会阻止您使用 EJB,反之亦然。在某些情况下,EJB 可以提供您可能想要在中使用 Spring 的应用程序中有用的服务。在没有 Spring 的情况下使用任何版本的 EJB 都将放弃众多宝贵的附加功能。事实上,正是支持 EJB 的游说团体(无论出于何种原因)将这两种技术描绘成直接的竞争对手。
这两种技术之间的重叠非常显著且在增长,但其增长速度不及 Spring 需求增长的速度
尽管这不是一个苹果对苹果的比较,但将 Spring 和 EJB 视为企业 Java 应用程序核心组件模型的替代方案是合理的。而且,很明显哪一个现在处于上升趋势。
我必须承认,我个人有一些满足感,因为我从 2003 年初就开始预测 EJB 将会过时,并且在此之前就认为 EJB 被过度使用了。在《J2EE without EJB》一书中,我详细分析了 EJB 模型的缺陷,以及它未能达到其既定目标或满足开发人员和客户需求的原因。当时,这些说法非常有争议。
EJB 3.0 在某些方面有所改进,但为时已晚:DI 功能不如实际世界所需的充分;拦截 API 认识到需要解决横切关注点的问题,但提供了迄今为止最不强大、最笨拙且最容易出错的解决方案(这一点我一直想写篇博文);它背负着与现在无关的上一代技术的向后兼容性的包袱;完整的 EJB 契约(比“简化的编程模型”长数百页)规定了一个具有过度开销的复杂运行时;尽管有语法糖,但它未能解决 EJB 中的一些缺陷,例如启动操作、单例和过时的线程模型。最后,它实际上被绑定到应用程序服务器环境,而此时基础设施正在发生变化。
我可以滔滔不绝地谈论这些缺陷,但职位数量则说明了成千上万公司的实际经验和结论。
请注意,我这里说的是会话 Bean 和消息 Bean;JPA 现在是一个单独的规范,基于现代技术,并且正在证明其价值。
EJB 的衰落对整个行业以及个体开发者意味着什么?
坦率地说,EJB 时代是一个异常。EJB 未能解决本世纪初的问题;对于未来的问题,它仍然不足。EJB 最初的大部分前提现在已经失效;该规范坚持向后兼容性并不能证明它所带来的权衡是合理的。它的衰落是向一个更灵活的新世界发展的自然结果,在这个世界里,像 OSGi 和朴实的 Servlet API 这样的技术被证明更加相关。当然,由于绝对数字仍然很高,EJB 不会很快完全消失。但趋势线清楚地表明,它确实正在成为遗留技术。
这个在职位要求上的里程碑恰好发生在我们在宣布 SpringSource Spring 认证计划之前,这很及时。现在 Spring 是市场上的一项重要技能,对雇主和开发人员来说,有一个明确的 Spring 知识衡量标准非常重要。
Spring 动力的进一步证明最近得到了 2007 年领先行业网站的统计数据。在 ServerSide 上,排名前 5 的文章中有 2 篇是关于 Spring 的,包括头条文章。在 InfoQ 上,排名前 10 的文章中有 3 篇是关于 Spring 的,头条文章(我的 Spring 2.0 更新)的页面浏览量是下一篇最受欢迎文章的 4 倍。