Spring Framework 交易支援模型的優點

傳統上，EE 應用程式開發人員在交易管理方面有兩種選擇：全域或本機交易，但兩者都有嚴重的限制。下一節將回顧全域和本機交易管理，然後討論 Spring Framework 的交易管理支援如何解決全域和本機交易模型的限制。

全域交易

全域交易可讓您使用多個交易資源，通常是關聯式資料庫和訊息佇列。應用程式伺服器透過 JTA 管理全域交易，JTA 是一個繁瑣的 API（部分原因是其例外模型）。此外，JTA UserTransaction 通常需要從 JNDI 取得，這表示您也需要使用 JNDI 才能使用 JTA。使用全域交易會限制應用程式程式碼的任何潛在重複使用，因為 JTA 通常僅在應用程式伺服器環境中可用。

以前，使用全域交易的首選方式是透過 EJB CMT（容器管理交易）。CMT 是一種宣告式交易管理形式（與程式化交易管理區分）。EJB CMT 消除了對交易相關 JNDI 查找的需求，儘管使用 EJB 本身就需要使用 JNDI。它消除了大部分但並非全部編寫 Java 程式碼來控制交易的需求。顯著的缺點是 CMT 與 JTA 和應用程式伺服器環境綁定。此外，它僅在選擇在 EJB 中（或至少在交易 EJB 外觀後面）實作業務邏輯時才可用。EJB 的總體缺點非常嚴重，以至於這不是一個有吸引力的提議，尤其是在面對引人注目的宣告式交易管理替代方案時。

本機交易

本機交易是資源特定的，例如與 JDBC 連線關聯的交易。本機交易可能更容易使用，但有一個顯著的缺點：它們無法跨多個交易資源運作。例如，使用 JDBC 連線管理交易的程式碼無法在全域 JTA 交易中執行。由於應用程式伺服器未參與交易管理，因此它無法協助確保跨多個資源的正確性。（值得注意的是，大多數應用程式都使用單一交易資源。）另一個缺點是本機交易會侵入程式設計模型。

Spring Framework 的一致程式設計模型

Spring 解決了全域和本機交易的缺點。它讓應用程式開發人員可以在任何環境中使用一致的程式設計模型。您只需編寫一次程式碼，它就可以在不同環境中受益於不同的交易管理策略。Spring Framework 提供宣告式和程式化交易管理。大多數使用者偏好宣告式交易管理，我們在大多數情況下都建議使用。

透過程式化交易管理，開發人員可以使用 Spring Framework 交易抽象化，該抽象化可以在任何基礎交易基礎架構上執行。透過首選的宣告式模型，開發人員通常只需編寫少量或完全不需要編寫與交易管理相關的程式碼，因此不依賴 Spring Framework 交易 API 或任何其他交易 API。

您是否需要應用程式伺服器進行交易管理？

Spring Framework 的交易管理支援改變了傳統規則，即企業 Java 應用程式何時需要應用程式伺服器。

特別是，您不需要僅僅為了透過 EJB 進行宣告式交易而使用應用程式伺服器。事實上，即使您的應用程式伺服器具有強大的 JTA 功能，您也可能會認為 Spring Framework 的宣告式交易比 EJB CMT 提供更強大的功能和更高效的程式設計模型。

通常，只有在您的應用程式需要處理跨多個資源的交易時，才需要應用程式伺服器的 JTA 功能，這並非許多應用程式的要求。許多高階應用程式改為使用單一、高度可擴展的資料庫（例如 Oracle RAC）。獨立交易管理員（例如 Atomikos Transactions）是其他選項。當然，您可能需要其他應用程式伺服器功能，例如 Java Message Service (JMS) 和 Jakarta EE Connector Architecture (JCA)。

Spring Framework 讓您可以選擇何時將應用程式擴展到完全載入的應用程式伺服器。過去只有兩種選擇的日子已經一去不復返了：使用 EJB CMT 或 JTA，或者使用本機交易（例如 JDBC 連線上的交易）編寫程式碼，如果您需要該程式碼在全域、容器管理的交易中執行，則面臨繁瑣的重工。使用 Spring Framework，只需要變更組態檔中的部分 Bean 定義（而不是您的程式碼）。