开发人员对Spring vs JavaEE的看法

在Java社区中，Spring vs JavaEE是一个永无止境的争论。 在这样的辩论中，人们组成一个团体，由两个传播者，建筑师和一个平台的核心粉丝组成，并且不断进行辩论。 参与辩论的人可能是负责平台选择的架构师。 但是开发人员会如何看待这次Spring vs JavaEE辩论？

我是同时使用Spring和JavaEE的Java开发人员，并且不属于Spring或JavaEE粉丝俱乐部。 在这里，我想就这个史诗般的Spring vs JavaEE辩论分享自己的想法。

1.商业（有时是政治）方面

在许多组织中，技术选择可能并不完全取决于开发人员的选择。 更具体地说，如果您在所谓的巨型企业组织中工作，那么很有可能会有架构团队来决定在项目中使用哪种平台/语言/框架/库。

除此之外，大型企业在选择技术平台时还考虑以下方面：

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

作为开发人员，我几乎不能影响上述任何方面的决策过程，尤其是当我是离岸开发中心的开发人员时。 所以我不用太担心这些事情。

2.如果您真的很擅长Spring / JavaEE，那么学习另一门也不难

当有人说我是JavaEE专家但我听不懂Spring时，我总是感到惊讶。 JavaEE和Spring都在相同的核心API（Servlet，JPA，JMS，BeanValidation等）上工作，不同之处在于谁将Spring或AppServer粘合在一起。

即使对于诸如依赖注入（Spring DI，CDI），REST（JAX-RS，SpringMVC）等事物有一些不同的API，它们的外观和行为也非常相似。

也许有人可以说CDI比Spring DI更安全。 在以下情况下，Spring和CDI的行为不一样吗？

• 如果只有一个Spring / CDI Bean，则使用@Autowired或@Inject进行注入可以正常工作
• 当有多个Spring或CDI bean实现时，注入失败，并抛出错误：“找到了多个可以注入的合格bean”，注入失败。
• 使用@Produces或@Bean注释方法将自定义对象提供为Bean提供程序

只要它们的行为类似，我不在乎它们是以类型安全的方式实现还是在其内部实现中使用基于String的映射。

怎样才能成为Spring的专家，却不懂JavaEE，反之亦然？ Spring专家学习JavaEE需要花费多少时间？

3.对“ Average Joe开发人员”更友好

我认为，到目前为止，许多人应该已经意识到，一项技术的成功可能并不完全取决于其优点，还取决于开发人员的采用。 要实现的最重要的事情是“并非每个软件开发人员都是摇滚明星开发人员。 与热情的技术忍者相比，普通的joe开发者更多”。 因此，为了使人们适应任何框架，应该对“ Average Joe Developer”友好。

我认为Spring通过提供更多工具（如SpringBoot，用户指南等）在做得很好。SpringSecurity，Spring Integration，Spring XD，Spring Social很好地满足了现代业务需求。 还请考虑一下Spring提供的各种模板，这些模板使操作变得简单而无需担心样板代码。

通过引入JBossForge，Wildfly Swarm等快速入门，JavaEE也表现出色。 我遇到了一些基于JavaEE的框架，例如Picketlink，它满足了安全性要求，但是我觉得它比应该的要复杂得多。

我要传达的观点是“您可以使用Spring进行JavaEE中的几乎所有工作”。 区别在于，这让普通的joe开发人员可以立即使用。

4.没有上下文的La脚论点

每当Spring vs JavaEE辩论出现时，人们就会组成两个小组，并进行无休止的辩论。 不幸的是，辩论集中在一些无用或过时的观点上。

XML重：

JavaEE爱好者首先开始说Spring是XML的重头戏，我讨厌XML等等。 如果您仍在使用早于2.5版的Spring并假设它仍然基于XML，那么我的朋友应该醒来，并转到http://spring.io

EJB不好（或）JSF不好

Spring迷们像EJB 2.x或JSF 1.x一样猛扑EJB和JSF。 如果他们真的关注EJB 3.x和JSF 2.x，那么他们根本不会争论。 不要凭您6年的EJB2.x经验来判断EJB3.x。

重或轻

我对“重量”的解释是基于运行时的足迹。 据我所知，当您将托管bean部署到JavaEE容器中时，容器将代理它并注入所有企业服务（事务，安全性等），如果是Spring，它将由Spring AOP完成。

我没有任何度量标准可以说哪个是比较重的Container Proxy或SpringAOP Proxy，但是我想可能没有太大的区别。

有些人将战争档案的大小视为其“重量”。 在那种情况下，将（JavaEE AppServer + war）的大小与（带有126个jars的SpringApp）进行比较，看看哪个比较轻：-)

JavaEE是基于标准的

拜托了伙计们！！！！

供应商锁定

我认为选择一个不会让您坚持某个特定供应商的平台是好的。 但是，仅基于迁移到其他实现的能力来选择选项是不正确的。 一年中从一台服务器切换到另一台服务器多少次？ 选择一个不会与供应商锁定您的平台是“很不错的选择”，但这并不是选择平台的主要因素。

我们不需要外部库

这称为“为争辩而争辩”。 向我展示任何没有依赖关系的真实应用程序。 如果您说我要开发自己的日志记录库，我要编写自己的HTTP客户端，我要开发自己的通用工具，那么您需要寻找一些没有“重新发明”的懒惰的架构师/开发人员。所有轮子的疾病。

5.不要看着人群说“你们都是白痴，因为您使用X，所以应该迁移到Y”。

这是我在许多社区站点（尤其是Reddit站点）上观察到的常见模式。 只需发布与JavaEE vs Spring相关的任何内容，就会有两个小组像其他一样抨击另一个小组，因为另一个小组没有使用他们喜欢的平台。

想一分钟。 如果说Spring不好，为什么会有很多人使用它并喜欢它。 如果JavaEE不好，为什么会有很多人从Spring切换到JavaEE。 每个平台上都有很多好东西。 尊重他人选择他们选择的任何选项。 如果可能的话，请问他们为什么选择彼此的理由，并了解您是否错过了任何事情。

只是说“你们都是不使用我喜欢的选项的白痴”并不能使他们使用您喜欢的技术。 实际上，这触发了人们的想法，提出了您最喜欢的平台烂点的清单。

如果您确实希望他们切换到自己喜欢的平台，请通过代码示例显示原因。 向他们展示使用您喜欢的平台和示例应用程序开发应用程序有多么容易。 写更多有关常见问题及其解决方法的文章。 将“ Average Joe Developer”安装到您喜欢的平台上。

作为一个热情的Java开发人员，我阅读了Spring vs JavaEE的讨论，希望可能有一些我不知道的事情，例如“在哪个领域比另一个领域更好”。 但是我发现70％的讨论都是关于la脚的争论，这对我来说不是很有趣。

我希望Spring和JavaEE阵营之间的战斗越来越多，并使他们的平台比其他平台更好。 归根结底，无论谁赢得了辩论，最终开发人员都将拥有更强大的平台。

翻译自: https://www.javacodegeeks.com/2015/06/a-developers-perspective-on-spring-vs-javaee.html