转载

开发者眼中的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之间比较的文章，那么亲爱的读者，你对二者有哪些看法呢，不妨与大家共同分享。

正文到此结束