开发者眼中的Spring与JavaEE

JavaEE与Spring

在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更够造成良性竞争，让自身变得愈来愈好。这样，不管谁最终赢得了竞争，受益的仍是广大开发者们，由于他们拥有了更为强大的平台。

 

转自http://www.infoq.com/cn/news/2015/07/spring-javaee