开发者眼中的 Spring 与 Java EE

在 Java 社区中，Spring 与 Java EE 之争是个永恒的话题。在这场争论中，来自两个阵营的布道师、架构师与铁杆粉丝都在不遗余力地捍卫着本方的尊严，并试图说服对方加入到自己的阵营当中，但结果却是双方都很难说服对方，每一方都有充分的理由表明自己的选择是正确的。参与到这场争论的有一些架构师，他们负责着平台的选择。那么对于普通开发者来说该如何思考这场旷日持久的 Spring 与 Java EE 之争呢？

Siva 是一位充满激情的 Java 开发者、开源布道师、知名博主，擅长 Java、Struts、Hibernate、Spring 等各项技术与框架。Siva 既使用过 Spring，也使用过 Java EE，但他既不是 Spring 的铁杆粉丝，也不是 Java EE 的忠实追求者。相反，他对于 Spring 与 Java EE 有着自己的理解和认识，并且在项目当中会根据具体需求选择适合的技术。近日，Siva分享了他对于 Spring 与 Java EE 的一些认识和理解，希望能对各位读者起到帮助作用。

业务方面

在很多组织中，技术选择并不完全是由开发者决定的。具体来说，如果你工作在一家大型的企业组织中，那么极有可能会有一个专门的架构师团队负责决定在项目中该使用什么平台、框架与库。除此之外，大型企业在选择技术平台时还会考虑如下几个方面：

• 平台、语言、框架与库的成熟度
• 商业支持
• 许可费用等

作为一名开发者，你可能无法影响上述几方面的决策制定过程，特别是对于那些处于离岸开发中心的开发者来说更是如此。因此，对于开发者来说，你可能无需过多关注于上述几个方面。

如果你非常熟悉 Spring，那么掌握 Java EE 也不是什么难事，反之亦然

我非常奇怪有人会说他是个 Java EE 专家，但却无法理解 Spring，反之亦然。无论 Java EE 还是 Spring 都使用了同样的核心 APIs（Servlet、JPA、JMS、BeanValidation 等），差别在于到底是什么将这些东西粘合到了一起，是 Spring 还是应用服务器。

虽然对于依赖注入（Spring DI、CDI）、REST（JAX-RS、SpringMVC）等存在着不同的 APIs，但他们彼此之间的行为却是非常类似的。可能有人会说 CDI 在类型安全上要比 Spring DI 更好，比如说：

• 如果只有一个 Spring/CDI Bean，那么使用 @Autowired 或是 @Inject 都是没问题的。
• 如果有两个 Spring 或 CDI Bean 实现，那么注入就会失败并抛出错误，说“找到了多个可注入的对象”。
• 使用 @Produces 或 @Bean 注解的方法可以实现自定义的 Bean 提供器。

只要二者行为类似，那么我就不关心谁的实现是更加类型安全的，谁在内部实现中采用了基于 String 的映射。我想说的是，怎么可能有人是 Spring 专家但却无法理解 Java EE 呢，反之亦然。一个 Spring 专家要花多长时间才能掌握 Java EE 呢？

Spring 与 Java EE 哪一个对开发者更加友好呢

我认为到现在为止，很多开发者应该能够认识到一项技术的成功与否其实并不完全取决于自身的优缺点，还要取决于开发者的使用率。我们要认识的重要一点是：“并不是每一个软件开发者都是明星开发者，还有很多处于中等水平的开发者”。为了让人们能够使用某一个框架或技术，框架或技术本身要贴合这一部分人的需求。我觉得 Spring 在这方面做得非常好，它提供了诸如 Spring Boot、用户指南等工具帮助开发者上手。Spring Security、Spring Integration、Spring XD、Spring Social 等项目都很好地解决了业务的需求。此外，Spring 还提供了各种各样的模板，让人们能够轻松上手开发而无需编写大量的样板代码。

Java EE 也通过 JBoss Forge、Wildfly Swarm 等工具帮助开发者上手。除了 Picketlink 之外，我几乎看不到有哪些 Java EE 框架提供了安全解决方案；但即便是 Picketlink，我觉得也过于复杂了。我想表达的观点是“Spring 能做到的事情，Java EE 基本上也都能做”。区别在于哪一个会为普通开发者提供开箱即用的支持。

缺乏上下文的争论

当 Spring 阵营与 Java EE 阵营的人开始争论时，注定是没有终点的。但遗憾的是，争论很多时候都围绕着毫无意义或是过时的点上面，比如说下面这些：

大量使用 XML

Java EE 粉丝一开始就会说 Spring 大量使用了 XML，我憎恶 XML 之类的。如果你还在使用 Spring 2.5 以下的版本，然后就认为 Spring 中充斥着大量的 XML，那么我想说你醒醒吧，到 http://spring.io 看看。

EJB 与 JSF 都是垃圾

Spring 粉丝会猛烈抨击 EJB 与 JSF，就好像他们还是 EJB 2.x 或 JSF 1.x 那样。如果仔细看看 EJB 3.x 与 JSF 2.x，那么他们就不会有这个想法了。不要拿 6 年前 EJB2.x 的老眼光看待现在的 EJB 3.x。

重量级与轻量级

这里的“重量级”指的是运行时情况。在将托管 Beans 部署到 Java EE 容器中时，容器会为其生成代理并注入所有的企业服务（事务、安全等），对于 Spring 来说，则是通过 Spring AOP 来实现的。这里其实没有办法判定哪一种方式更加重量级，容器代理呢，还是 Spring AOP 代理，不过我觉得二者之间的差别并不太大。有些人会将部署的 war 包大小作为判断是否“重量级”的一个依据。在这种情况下，Java EE 应用服务器 + war 与 Spring App + 126 jar 之间的差别倒是很明显。

厂商锁定

我认为选择平台时可以不依赖于某个特定的厂商是很重要的，不过纯粹基于可以迁移到另外一个实现这一理由来选择平台也是不恰当的。可以想想，你有多少机会会从一个服务器迁移到另外一个服务器？选择一个平台时不必锁定到某个厂商是个“锦上添花”的行为，但绝不应该将其作为关键因素。

我们不需要外部程序库

这就是所谓的“为了争论而争论”。给我看看有哪个应用不需要其他依赖？如果你说你要开发自己的日志库，编写自己的 HTTP 客户端、开发自己的通用库，那么我只能说这样的开发者也算是奇葩了，放着现成的不用，还要“重新发明轮子”。

你现在使用的是 X，你应该迁移到 Y

我发现很多社区站点都存在这样的观点，特别是在 Reddit。当有人发出关于 Java EE 与 Spring 的帖子时，就会有两拨人参与进来，猛烈抨击对方，原因就是对方没有使用自己钟爱的平台。先想一想，如果 Spring 是垃圾，那怎么还会有那么多人使用并喜欢它呢。如果 Java EE 不好，那为何还会有人从 Spring 迁移到 Java EE 上呢。每个平台都有长处。你要做的就是尊重他人。如果可能，问一下他们为何要选择这个平台，是不是有你不知道的理由在里面呢？

作为一名热情的 Java 开发者，我真心希望在关于 Java EE 与 Spring 之间的争论中能找到我之前不了解的东西，比如说“在哪些情况下，Spring 要比 Java EE 更合适；在哪些情况下，Java EE 要比 Spring 更好”。我希望 Spring 与 Java EE 更够形成良性竞争，让自身变得越来越好。这样，无论谁最终赢得了竞争，受益的还是广大开发者们，因为他们拥有了更为强大的平台。

InfoQ 也发表过多篇关于 Spring 与 Java EE 之间比较的文章，那么亲爱的读者，你对二者有哪些看法呢，不妨与大家共同分享。