Java社區中有很多關于Spring vs Java EE的話題。 一群人會爭辯說您應該使用一個而不是其他。等等。當我看到這一點時，我不禁要想為什么我們不能同時使用它們呢？ 實際上，我認為有效地使用它們會為構建基礎架構創建一個偉大的技術堆棧，例如對于一家大型公司而言，該公司希望提供一個可以托管和運行許多不同應用程序和項目的通用平臺。

為什么將Spring和Java EE結合在一起？

在編寫軟件時，我們創建和構建可重復使用的庫/框架，并幫助我們更快地完成工作。 Spring是一個像瑞士軍刀一樣的庫，它允許以一種非侵入性的方式構建應用程序，并具有許多更簡單的包裝器和幫助器類。 這就是我所說的“對開發人員友好”的庫。

但是，許多人沒有意識到Spring只是一個包含對許多可以簡化開發工作的包裝器的庫。 例如，Spring具有一個Web框架層，可讓您編寫MVC Web應用程序，但是您仍然需要Servlet容器（服務器）。 Spring提供的數據層主要包裝了其他JPA / Hibernate / JDBC，這些JPA / Hibernate / JDBC很好地集成在了它們的IoC容器中，但是實際的ORM實現不在Spring之外（例如：Hibernate）。 Spring包裝了JMS甚至JNDI進行開發，但是您仍然需要JMS服務器或JNDI提供程序。 Spring具有事務管理器抽象層，但它只是一個包裝器（對于單個數據庫，實際上是數據庫供應商提供了交易保證的ACID屬性，而不是Spring）。 如果要在多個資源（例如JMS和數據庫，或多個數據庫）上進行原子事務，則仍然需要“真實”事務管理器（JTA）！

所以現在您看到，要構建成功的企業應用程序，您需要在許多供應商提供的功能之上使用Spring。 如果您不小心，可能會陷入難以集成和部署的許多專有服務中。 這就是Java EE的用武之地。這是規范布局，供應商必須以標準方式提供大多數這些服務。 因此，任何JEE法規遵從性服務器都將提供帶有標準API的服務，該標準API應該以類似的方式工作。

現在必須保持平衡。 根據我的經驗，您執行的標準越多，獲得的“對開發人員友好的”就越少。 但是，與此同時，如果沒有標準，則很難提供通用的基礎結構，例如API，運行時服務器甚至OS環境進行部署。 這就是為什么我認為將Spring與Java EE相結合將為IT社區帶來一個更實用和有效的平臺的原因。

選擇技術棧

并非每個項目的創建都是平等的，他們的需求在很大程度上不同。 因此，不可能提供一個滿足所有項目需求的通用技術堆棧。 但是我們當然可以嘗試創建一個可以滿足大多數項目需求的通用工具。 另外，選擇一個具體的庫/堆棧是非常有根據的，無論選擇哪種實際實現，總是會有利弊的。 考慮到這一點，我將嘗試提出自己對技術棧的個人選擇，我認為它將為承載各種項目和應用程序提供最靈活的平臺。 特別是在大型公司環境中。

我將選擇Java EE應用程序服務器作為通用平臺。 從中，我將選擇一些“對開發人員友好”的庫來替換（或在頂部添加）一些現有的EE標準，以提高生產率。 我認為EE已經走了很長一段路，并且在每次規范迭代中都變得更好，但是我仍然覺得將POJO服務連接在一起時，使用Spring作為IoC容器比使用CDI有更大的靈活性。 另外，Spring框架帶有非常靈活的MVC層，與普通的Servlet API相比，該層有效且易于開發。

使用Java EE 6，服務器必須提供兩個配置文件。 因此，讓我們從這兩個視圖開始探索堆棧。

JEE Web配置文件–基于Web的更輕便的應用程序

• 使用Spring MVC（控制器，表單，驗證，ModelAndView和IoC配置）代替普通的Servlet API編程。
• 使用盡可能多的POJO編寫后端業務服務邏輯，并使用Spring IoC進行連接。 不要濫用這個。 我個人認為，與CDI相比，Spring IoC更靈活，更易于使用。
• 將JPA用于數據服務層而不是JDBC API編程。
• 使用JSON數據交換格式。 根據經驗，與XML相比，JSON更加高效且易于使用。
• 視圖選項：
  • 使用格式正確的xhtml / Bootstraps / jquery / AJAX->如果您只需要靜態頁面和一些客戶端交互
• Servlet 3.0現在支持異步請求。 這解決了Web域中的許多難題。 如果需要，可以利用它！ （最新的Spring MVC已經對此提供支持。）

JEE 6完整個人資料–完整EE功能應用程序

• 在Web配置文件中上述所有內容之上。
• 將JMS用于屬于點對點或發布/訂閱域的任何消息傳遞需求。
• 當您需要原子事務進行多個數據庫和/或JMS交付時，請使用JTA。
• 使用標準的JAX-RS（RESTful Web服務API）公開外部服務。 使用JSON數據交換格式。
• 使用一致的Spring IoC進行服務注入。 與CDI相比，它更靈活，更易于使用。
• 如果可能的話，使用POJO服務并通過Spring代替EJB進行連接。 我發現它們更易于測試和開發。
• 加上它所支持的其他任何EE規范，例如（JavaMail和JCA等。通常，Spring也會為這些API提供更簡單的包裝。）

Apache Camel –輕量級ESB

Camel項目不是EE標準。 但是，我的經驗是，使用簡單的駱駝路線/工作流程可以輕松完成許多常見的IT工作。 Camel的開發和樣式易于理解且易于測試。 它可以作為獨立的應用程序/服務運行，也可以作為Web應用程序的一部分運行。 我相信，在上面的通用平臺之上添加一個巨大的價值。 您將在需要以下各項時使用它：

• 對于任何類似工作流流程的集成模式（例如：將文件輪詢器橋接到Web服務，將JMS隊列橋接到數據庫等）
• 用于創建業務工作流程。
• 適用于任何ETL工作流程。
• 為了輕松將業務需求工作流映射到代碼邏輯流程

使用哪個EE應用程序服務器

我認為這也是主觀的，但是我們需要選擇適合我們業務需求的產品。 我個人更喜歡JBoss，因為它是開源的，但是他們提供了其應用服務器的商業支持版本。 作為基于開源的產品，它使開發人員在學習和探索平臺方面具有更大的靈活性。 我也看到了他們內部項目的許多好處，例如開放的測試工具和庫，這些都使平臺開發人員受益。

Tomcat服務器呢？

Tomcat是一個非常著名的Servlet容器。 但是，它只是一個支持Servlet / JSP應用程序的Web容器。 它不提供Java EE服務器提供的JMS或JTA功能。 事實上，僅使用一個簡單的Tomcat服務器就可以滿足許多Web應用程序的需求。 但是，在大型IT環境中，您經常需要僅由Java EE服務器提供的其他服務。 在許多情況下，人們將只需要運行Tomcat webapp并在需要時橋接到其他Java EE服務器。

使用JEE6，可以將Web配置文件簡化為大多數Web容器功能，這應該使服務器啟動更快（加載更少的額外服務）。 但是，如果應用程序需要額外的EE功能，我們提供的平臺將能夠支持它們。

參考：在A Programmer's Journal博客上 ，選擇我們JCG合作伙伴 Zemian Deng的技術堆棧來構建通用平臺 。

翻譯自: https://www.javacodegeeks.com/2013/06/choosing-technology-stack-to-build-a-common-platform.html

總結

以上是生活随笔為你收集整理的选择技术栈构建通用平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。