Spring 3.0 vs Java EE 6.0

Question

我正面临着一种情况...

我被要求就在Spring 3.0和Java EE 6.0之间进行Java EE开发时采用哪种方法提出建议。我过去是，现在仍然是Spring2.5的推动者，而不是经典的JavaEE5开发，特别是使用JBoss，我甚至将旧的应用程序迁移到Spring，并影响了这里的开发策略的重新定义，以包括Spring特定的API，并帮助开发了一个战略计划，以促进更轻量级的解决方案，如Spring + tomcat，而不是JBoss的重量级解决方案。现在，我们只是将JBoss用作Web容器，具有我所称的“容器内的容器悖论”，即有Spring应用程序，其大部分API在JBoss中运行，所以我们正在迁移到tomcat的过程中。

然而，随着Java EE 6.0的到来，许多特性使得Spring在当时很有吸引力，简单的部署，较少的耦合，甚至某种D.I等等，似乎都以这样或那样的方式被模仿了。JSF2.0、JPA2.0、WebBeans、WebProfiles等。

所以，问题是...

从您的角度来看，考虑到Java EE 6.0提供的新视角，继续投资于像Spring这样的非标准Java EE开发框架是多么安全和合乎逻辑？

我们可以再谈3到4年的Spring开发吗?或者您是否建议尽早采用Java EE 6.0API及其实践？

如果您对此有任何见解，我将不胜感激。

Answer 1

关键点IMHO不是特征之一。在这一点上，Spring永远领先于JavaEE，因为它对于OpenSource VS来说是很自然的。一个标准。因此，一个事实是，与JavaEE相比，Spring获得新特性的时间要早得多(例如，容器集成测试是JavaEE 6中的一个新特性，在Spring中已经存在很长时间了)。

IMHO最重要的一点是管理和开发的生命周期之一。当您选择JavaEE时，您将编程模型与您的基础设施捆绑在一起。通常，应用服务器供应商并不是最快采用新标准版本的公司(怪罪于WebSphere、JBoss等等)。所以这意味着在年底之前，我们可能还看不到大型厂商生产支持JavaEE 6的产品。

即使是这样，你仍然必须克服管理、IT部门和预算控制经理的障碍，才能愿意升级到这个闪亮的新版本。从这一方面来说，JavaEE 6甚至不是许多商店的选择。您可以选择将您的应用程序部署到任何您喜欢的位置？你想选择Glassfish来制作吗？去吧，试一下。大多数商店并不处于这种“舒适”的境地。

恰恰相反的是:春天。将编程模型与基础设施解耦。使用当前的3.0.x，在Tomcat或遗留应用服务器中使用@Inject、JPA2等。

Answer 2

如果你已经是一家Spring商店了，为什么还要切换呢？你对它很满意，它做了你想做的，它是积极开发的，你可能不会很快在Tomcat之外运行，因为Tomcat非常成熟，可以在任何地方运行。因此，Java可能建议的任何关于可移植性的承诺都将不复存在。

我看不出有什么理由要放弃Spring。

Answer 3

既然Will和Oliver已经说了最关键的话，我只想补充一句：“如果它有效并完成了工作，那么就别管它了！”“更新的”和“标准化的”并不总是等于“更好的”，事实上它很少-新的东西是笨拙和错误的，(这对我来说是最重要的)没有得到广泛的支持。如果Java EE 6的其余部分像JSF2.0一样“标准化”(以及所有的Rich/Ice/Prime/WhateverFaces)，那么相信我，现在还是坚持使用Spring吧。许多公司坚持使用老一点的技术是有原因的(稳定性> *)，Spring已经在市场上存在了很多年了，而且已经很成熟了。

@Edit:特别是对于@ymajoros:由于多种原因，JSF ( 1.x和2.x)是一个有缺陷的标准，并且仅在极少数情况下有用(例如，当您创建小型、简单的CRUD网站时，或者当您是Java EE爱好者时)：

• 创建新组件是一件很痛苦的事情。因为它是一个基于组件的框架，所以我认为它会让事情变得更容易，而不是更难()。目前，我更喜欢在后端方法上使用JS+Java，因为它实际上更容易让我在那里创建组件。JSF的唯一优点是它有大量的组件库。当它们不起作用时，问题就开始了，你想要改变一些东西或者创建你自己的component.
• exception处理是一团糟(或者在过去一两年里有什么改变了吗？) Java有状态太多的问题--很少有糟糕的决策，你的项目中有一个糟糕的开发人员，你的应用程序的一半可能是有状态的，而标准的serialized.
• the UI部分没有(或者至少在我写这篇回答的时候没有)覆盖来自

的大多数集合(实际上只涵盖了列表中的数据结构)。

至于您喜欢的标准:他们最终以某种方式将JSF与JAX-RS集成在一起了吗？因为上一次我检查了这些规范是完全分离的，即使你可以做很多改进。例如，为什么我不能在支持bean中用@Path注释一个方法，这样它就可以同时由REST请求和JSF请求处理？

也许有些(全部？)这些问题现在已经解决了，但是当我写这个答案的时候，它们只是JSF和标准所有不好的东西中的一小部分。

目前，如果我想创建一个非常小、简单的CRUD应用程序，我会使用Play 2.0 (尽管它是一个巨大的反模式)或类似RoR的应用程序。当我想要创建一个大型的“企业级”应用程序时，我会抓取一个JS框架(如ExtJS)和一个JS组件库，并将其与Java (例如Spring)结合起来，然后我就可以做我需要做的事情，而这个所谓的标准不会带来任何开销。

当然，JEE6中也有一些很酷的部分，比如JPA2、JAX-RS2，bean验证也不是那么糟糕。但是仅仅因为他们称之为“标准”而使用整个标准堆栈(正如我在上面提到的，大多数规范甚至没有协同作用)，在我的非常的谦虚观点中，是错误的。