假定你決定直接使用JDBC或Hibernate的事務來避免JTA的開銷。一旦你需要與多個數據源打交道，你會不得不找出所有事務管理代碼并用JTA事務來替換它們。這難道不具吸引力？這導致包括我在內的大多數J2EE開發者推薦只使用全局JTA事務，并用像Tomcat這樣的簡單Web 容器來有效管理事務程序。不管怎樣，使用Spring事務抽象，你只要重新配置Spring來使用JTA，而不是JDBC或Hibernate的事務策略就可以了。這是一個配置的修改，不是代碼變更。因此，Spring讓你的應用程序能隨意縮放。
AOP
從2003年起在企業關注問題上(例如一般使用EJB來做的事務管理)使用AOP解決方案大家有了很大的興趣。
Spring的AOP支持的首要目標是為POJO 提供J2EE支持。Spring AOP能夠在應用服務器之間移植，所以沒有廠商綁定的風險。它可以工作在web 容器或者是EJB容器中，而且已被成功應用于WebLogic、Tomcat、JBoss、Resin、Jetty、Orion和其他很多應用服務器及web 容器上。
Spring AOP支持方法攔截。所支持的關鍵AOP概念包括：
攔截(Interception)：自定義的行為能插入到任何接口和類的方法調用的前面或后面。這和AspectJ 術語中的“around advice”相近。
引入(Introduction)：一個執行邏輯(advice)會導致一個對象實現額外的接口。這會引起繼承混合。
靜態和動態切入點：在程序執行過程中指定發生攔截的地方。靜態切入點關注方法簽名；動態關注點還能考慮被計算處的方法參數。切入點與攔截器分開定義，這使得一個標準攔截器可以被用在不同應用程序和代碼上下文中。
Spring支持有狀態的(每個執行邏輯對象一個實例)和無狀態的(所有執行邏輯用一個實例)攔截器。
Spring不支持字段攔截。這是一個經過深思熟慮的設計決定。我總覺得字段攔截不符合封裝原則。我更愿意認為AOP是OOP的一個補充而不是與它沖突。在5到10 年后，我們在AOP的學習曲線上走得更遠了很自然地會覺得應該在應用程序設計的桌面上給AOP留個位置。(那時像AspectJ 這樣的基于語言的解決方案會比今天更具吸引力。)
Spring用動態代理(需要存在一個接口)或運行時CGLIB字節碼生成(這使得類的代理成為可能)來實現AOP。這兩種方法能在任何應用服務器中運行，也能工作在獨立環境中。
Spring是第一個實現了AOP聯盟接口(www.sourceforge.net/projects/aopalliance)的AOP框架。這些代表了不同AOP框架的攔截器也許可以協同工作。
Spring集成了AspectJ，提供了將AspectJ 的方面無逢集成到Spring應用程序中的能力。從Spring 1.1 開始已經可以用Spring的IoC容器依賴注入AspectJ 的方面，就像任何Java 類一樣。因此AspectJ 的方面可以依賴于任何Spring管理的對象。對即將到來的AspectJ 版本5 的集成更令人激動，基于注釋驅動切入點，AspectJ 開始提供用Spring依賴注入任何POJO的能力。
因為Spring攔截的是實例級對象而不是類加載器級的，所以可以在同一個類的不同實例上使用不同的執行邏輯，或把未攔截的對象和已攔截的對象一起使用。
也許Spring AOP的常見用途是用于聲明性事務管理。這構建于前面討論過的事務抽象之上，并且可以用任何POJO 進行聲明性事務管理。依靠事務策略，底層機制可以是JTA、JDBC、Hibernate或是其他任何提供事務管理的API。
以下是與EJB CMT的主要不同：
事務管理可以應用于任何POJO。我們建議業務對象實現接口，這只是一個好的編程習慣，不是由框架所強制的。
通過使用Spring的事務API在一個事務性POJO 中實現可編程的回滾。我們為此提供了靜態方法，使用ThreadLocal變量，所以你不必傳播一個類似EJBContext這樣的上下文對象來保證回滾。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
