这个问题经常出现。 我的新项目也在2011年11月发布。 在这个新的Enterprise Java项目中，我将使用Java EE（JEE）代替Spring框架。

我知道：关于此主题的文章，博客和论坛讨论都可以找到。 为什么还需要一个？ 因为许多博客都在谈论Java EE的旧版本，或者它们不是中立的（我希望是中立的）。 而且由于许多人仍然认为感谢EJB很繁重！ 而且因为时间已经改变：现在是Java EE 6时代，J2EE已死。 最后！ 最后，因为不仅可以使用JEE 6，而且还可以使用多个应用程序服务器（不只是Glassfish作为参考实现）。 我不想发动一场火焰战争（已经存在太多），我只想描述一下我对JEE与Spring“战斗”的个人看法……

因此，我认为从简短的概述和两种选择的历史入手非常重要。 然后，我将列出两者的差异，并解释为什么对于大多数新的Java项目而言，这些差异导致我使用JEE而不是Spring。 我明确地在谈论新的应用程序。 如果必须扩展现有应用程序，请继续使用现有框架！

另一个免责声明：我正在谈论关键任务企业Java应用程序。 我不是在谈论一些内部应用程序或其他不重要的内容。 我还更喜欢将Scala，Groovy和Clojure的组合持久化到NoSQL数据库，同时将其部署在JBoss OpenShift或VMware CloudFoundry等PaaS云服务中……

有关JEE和Spring的一般信息

首先，我想总结一些有关JEE和Spring的一般信息：

• 最后，这两种选择都由几个库组成，开发人员可以使用它们来创建企业应用程序。
• 两者都可以在大多数用例中使用，它们具有非常相似的功能（业务逻辑，事务，Web框架等等）–它们仅在实现上有所不同（例如，Spring中的声明性事务与JEE中的约定）。
• 您也只能使用一个或某些可用库。 您甚至可以将JEE和Spring东西结合起来。
• 通常，关键问题是：“我应该使用JEE（即，尤其是EJB，JPA，CDI等）或Spring核心框架（即，尤其是Spring Application Context，Spring Bean等）来实现我的新应用程序吗？ 通常，您可以选择两者，从最终用户的角度来看都没关系。 但是您不应该将两者合并，这只会带来更高的复杂性。
• 关于选择哪种替代方案一直存在争议。 中立地讨论这个问题非常困难。 这就是为什么几乎所有讨论都以赞美一个框架然后抨击另一个框架而结束的原因（我希望在本博文中保持中立）。

历史：J2EE太可怕了，因此Spring帮助了！

J2EE太可怕了。 如此多的XML配置，如此之多的接口以及如此la脚的应用服务器。 这就是创建Spring框架的原因。 它解决了J2EE的许多问题。 它轻巧，易于使用，并且可以将应用程序部署在Web容器（例如Tomcat）中，而不是部署在笨重的J2EE应用程序服务器中。 部署花费了几秒钟而不是15分钟。 不幸的是，JRebel当时不存在。 Spring框架不是J2EE的标准，但是它变得非常普遍，并且产生了一个庞大的社区。

JEE“偷”了轻量级的Spring创意！

一切始于一些捷径的改变。 J2EE已死。 新的快捷方式是JEE。 JEE 5诞生于2006年。它“窃取”了许多好的，轻量级的想法，例如来自Spring和其他框架的“基于配置的约定”或“依赖注入”。 是的，JEE应用服务器仍然很笨重，几乎不可能进行测试。 尽管如此，开发JEE应用程序对JEE 5还是很有趣的。创建EJB时不必编写20个接口。 哇，太神奇了！

然后，2009年发布了JEE 6。 开发是如此简单。 最后！ 例如，您只需要添加一个注释，您的EJB就可以使用了！ 当然，Spring框架的开发人员没有睡觉。 添加了许多新内容。 今天，您可以创建一个没有任何XML文件的Spring应用程序，就像几周前我在“ No Fluff Just Stuff”文章中所读到的一样。 此外，在Spring堆栈中添加了一些非常酷的框架，例如Spring Integration，Spring Batch或Spring Roo。
如今（2011年11月），JEE和Spring都非常普及，并拥有庞大的社区。 两者都有很多信息，例如书籍，博客，教程等。 因此，在描述了JEE和Spring的发展之后，为什么在大多数新的Java项目中使用JEE？

JEE和Spring的优缺点

必须做出决定。 在新项目中使用哪种替代方法？ 让我们看看两者的利弊。 我将在Spring的优势上添加一个“ BUT”-这些“ BUT”是我更喜欢JEE而不是Spring的原因。

JEE的优势

• JEE是一组标准规范，因此与供应商无关。 通常，规范存在几种实现。
• 可持续性：嗯，这是几个大型公司支持的标准的优势。
• 是的，信不信由你，测试是可能的！ 轻量级的应用程序服务器和框架（例如Arquillian）进入了JEE世界！
• 约定超越配置无处不在，而不是明确的（我知道有些人会不同意这是一个优势）。

弹簧的优点

• 您不需要笨重的JEE应用程序服务器，可以将应用程序部署在Web容器（例如Tomcat）中。

但是：JEE应用程序服务器并不像几年前那样繁重。 此外，也可以使用JEE Web配置文件。 您不必使用Tomcat或Jetty来减轻重量！

• Spring提供了JEE标准无法提供的功能，例如Spring Batch。

但是：您可以毫无问题地将这样的库添加到JEE项目中。 如果需要，还可以添加其他Spring库，例如JDBCTemplate或JMSTemplate（它们有助于减少一些样板代码）。

• Spring提供了更多的灵活性和功能，例如，面向方面的编程比JEE拦截器更强大。

但是：在大多数项目中，您不需要这种灵活性或功能。 如果确实需要，请使用Spring，而不是JEE-当然！

• 更快的发布（因为它不是标准，只有一个供应商）。 对市场需求的反应要快得多。 当前的一些示例：云，移动，社交计算。

但是：我看到的所有企业项目（包括许多不同的客户）都不那么灵活。 企业应用程序不会每月或每年更改。 如果有一个项目，可以很容易地更改版本，那么在某些情况下，Spring可能比JEE更好。 但是在大多数企业项目中，您不能简单地从Spring 2.5升级到Spring 3.x或从JEE 5升级到JEE6。我希望这是可能的，但是在拥有数千名员工的大公司中，灵活性和政治规则较低。

结论：我将在大多数新的Enterprise Java项目中使用JEE

由于我在“ BUT”部分中针对Spring进行解释的原因，我将在大多数新的Enterprise Java项目中选择JEE。 不过，有时我也会使用Spring库（例如Spring Batch）。 有时，我什至必须使用Spring（如果我需要它的灵活性或强大功能），但是只有这样，我才选择它。 当然，对于现有项目，我将继续使用已经使用的框架。 我可能不会将Spring 2.5应用程序迁移到JEE，而是将其迁移到Spring 3.x！

因此，我已经说明了为什么在大多数新的Enterprise Java项目中使用JEE的原因。 如果我错过了一些事情，或者您有其他意见（可能有很多人），则可以在评论中让我失望。 我感谢所有的“非战争”讨论……

参考： 为什么我将在 JCG合作伙伴的 2012年新的Enterprise Java项目中使用Java EE而不是Spring   关于Java EE / SOA /云计算的博客的Kai Wahner。