這個問題經常出現。 我的新項目也在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。