spring中的AOP與IOC

在J2EE的整個發展歷程中，如今正是一個很是時刻。從不少方面來講，J2EE都是一個偉大的成功：它成功地在從前沒有標準的地方創建了標準；大大提高了企業級軟件的開放程度，而且獲得了整個行業和開發者的普遍承認。然而，J2EE在一些方面已經開始捉襟見肘。J2EE應用開發的成本一般很高。J2EE應用項目至少和從前的非J2EE項目同樣容易失敗——若是不是更容易失敗的話。這樣的失敗率高得讓人難以接受。在這樣的失敗率之下，軟件開發幾乎變成了碰運氣。而在J2EE遭遇失敗的場景中，EJB一般都扮演着重要的角色。所以，J2EE社羣不斷地向着更簡單的解決方案、更少使用EJB的方向發展[1]。然而，每一個應用程序都須要一些基礎設施，拒絕使用EJB並不意味着拒絕EJB所採用的基礎設施解決方案。那麼，如何利用現有的框架來提供這些基礎設施服務呢，伴隨着這個問題的提出，一個輕量級的J2EE解決方案出現了，這就是Spring Framework。

　　Spring是爲簡化企業級系統開發而誕生的，Spring框架爲J2EE應用常見的問題提供了簡單、有效的解決方案，使用Spring，你能夠用簡單的POJO(Plain Old Java Object)來實現那些之前只有EJB才能實現的功能。這樣不僅是能簡化服務器端開發，任何Java系統開發都能從Spring的簡單、可測試和鬆耦合特徵中受益。能夠簡單的說，Spring是一個輕量級的反向控制（IoC）和麪向切面編程（AOP）容器框架[3]。Spring IoC，藉助於依賴注入設計模式，使得開發者不用理會對象自身的生命週期及其關係，並且可以改善開發者對J2EE模式的使用；Spring AOP，藉助於Spring實現的攔截器，開發者可以實現以聲明的方式使用企業級服務，好比安全性服務、事務服務等。Spring IoC和 Spring ; AOP組合，一塊兒造成了Spring，這樣一個有機總體，使得構建輕量級的J2EE架構成爲可能，並且事實證實，很是有效。沒有Spring IoC的Spring AOP是不完善的，沒有Spring AOP的Spring IoC是不健壯的。本文是以Spring架構的成功的實際商務系統項目爲背景，闡述了反向控制原理和麪向切面的編程技術在Spring框架中的應用，同時抽取適量代碼示意具體應用，並和傳統開發模式進行對比，展現了Spring framework的簡單，高效，可維護等優勢。

　　一、Spring IoC 1.1 反向控制原理

　　反向控制是Spring框架的核心。可是，反向控制是什麼意思？到底控制的什麼方面被反向了呢？2004年美國專家Martin Fowler發表了一篇論文《Inversion of Control Containers and the Dependency Injection pattern》闡述了這個問題，他總結說是得到依賴對象的方式反向了，根據這個啓示，他還爲反向控制提出了一個更貼切的名字：Dependency Injection(DI 依賴注入)。

　　一般，應用代碼須要告知容器或框架,讓它們找到自身所須要的類,而後再由應用代碼建立待使用的對象實例。所以，應用代碼在使用實例以前，須要建立對象實例。然而，IoC模式中,建立對象實例的任務交給IoC容器或框架(實現了IoC設計模式的框架也被稱爲IoC容器)，使得應用代碼只須要直接使用實例，這就是IoC。相對IoC 而言，「依賴注入」的確更加準確的描述了這種設計理念。所謂依賴注入，即組件之間的依賴關係由容器在運行期決定，形象的來講，即由容器動態的將某種依賴關係注入到組件之中。

　　1.2 IoC在Spring中的實現

　　任何重要的系統都須要至少兩個相互合做的類來完成業務邏輯。一般，每一個對象都要本身負責獲得它的合做（依賴）對象。你會發現，這樣會致使代碼耦合度高並且難於測試。使用IoC，對象的依賴都是在對象建立時由負責協調系統中各個對象的外部實體提供的，這樣使軟件組件鬆散鏈接成爲可能。下面示意了Spring IoC 應用，步驟以下：

　　（1）定義Action接口，併爲其定義一個execute方法，以完成目標邏輯。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一書中提出「Programming to an Interface，not an implementation」的原則，這裏首先將業務對象抽象成接口，正是爲了實施這個原則。

　　（2）類UpperAction實現Action接口，在此類中，定義一個String型的域message，並提供相應的setter和getter方法，實現的execute方法以下：

public String execute (String str) {   　return (getMessage () + str).toUpperCase () ; }

　　（3）編寫Spring配置文件（bean.XML）

＜beans＞   ＜bean id="TheAction" class="net.chen.spring.qs.UpperAction"＞ ＜property name="message"＞ ＜value＞HeLLo＜/value＞ ＜/property＞ ＜/bean＞ ＜/beans＞

　　（4）測試代碼

public void testQuickStart () {   　ApplicationContext ctx=new 　FileSystemXmlApplicationContext ("bean.xml"); 　Action a= (Action) ctx.getBean ("TheAction"); 　System.out.println (a. execute ("Rod Johnson")); }

　　上面的測試代碼中，咱們根據"bean.xml"建立了一個ApplicationContext實例，並今後實例中獲取咱們所需的Action實現，運行測試代碼，咱們看到控制檯輸出：

……   HELLO ROD JOHNSON

　　仔細觀察一下上面的代碼，能夠看到：

　　（1）咱們的組件並不須要實現框架指定的接口，所以能夠輕鬆的將組件從Spring中脫離，甚至不須要任何修改，這在基於EJB框架實現的應用中是不可思議的。

　　（2）組件間的依賴關係減小，極大改善了代碼的可重用性。Spring的依賴注入機制，能夠在運行期爲組件配置所需資源，而無需在編寫組件代碼時就加以指定，從而在至關程度上下降了組件之間的耦合。

　　Spring給咱們帶來了如此這般的好處，那麼，反過來，讓咱們試想一下，若是不使用Spring框架，回到咱們傳統的編碼模式，狀況會是怎樣呢？

　　首先，咱們必須編寫一個配置文件讀取類，以實現Message屬性的可配置化。

　　其次，得有一個Factory模式的實現，並結合配置文件的讀寫完成Action的動態加載。因而，咱們實現了一個ActionFactory來實現這個功能：

public class ActionFactory {   　public static Action getAction (String actionName) {Properties pro = new Properties (); 　try { 　　pro.load (new FileInputStream ("config.properties")); 　　String actionImplName =(String)pro.get(actionName); 　　String actionMessage =(String) pro.get (actionName+"_msg"); 　　Object obj =Class.forName (actionImplName).newInstance (); 　　BeanUtils.setProperty(obj,"message",actionMessage); 　　return (Action) obj; 　} catch (FileNotFoundException e) { 　　…… 　} }

　　配置文件則採用properties文件形式以下所示：

TheAction=net.chen.spring.qs.UpperAction   TheAction_msg=HeLLo

　　測試代碼也做相應修改。如今不論實現的好壞，總之經過上面新增的多行代碼，終於實現了相似的功能。若是如今有了一個新的需求，這樣這個ActionFactory每次都新建一個類的實例，顯然這對系統性能不利，考慮到咱們的兩個Action都是線程安全的，修改一下ActionFactory，保持系統中只有一個Action實例供其它線程調用。另外Action對象建立後，須要作一些初始化工做。修改一下ActionFactory，使其在建立Action實例以後，隨即就調用Action.init方法執行初始化。Action的處理這樣就差很少了。下面咱們來看看另一個Factory

　　……

　　每每這些系統開發中最多見的需求，會致使咱們的代碼迅速膨脹，而Spring IoC的出現，則大大緩解了這樣的窘境。經過以上實例，能夠看出，Spring IoC爲咱們提供了以下幾方面的優點：

　　（1）應用組件不須要在運行時尋找其協做者，所以更易於開發和編寫應用；

　　（2）因爲藉助於IoC容器管理組件的依賴關係，使得應用的單元測試和集成測試更利於展開；

　　（3）一般，在藉助於IoC容器關係業務對象的前提下，不多須要使用具體IoC容器提供的API，這使得集成現有的遺留應用成爲可能。

　　所以，經過使用IoC可以下降組件之間的耦合度，最終，可以提升類的重用性，利於測試，並且更利於整個產品或系統集成和配置。

 

二、Spring AOP

　　2.1 面向切面編程基礎

　　一般，系統由不少組件組成，每一個組件負責一部分功能，然而，這些組件也常常帶有一些除了核心功能以外的附帶功能 。系統服務如日誌、事務管理和安全常常融入到一些其餘功能模塊中。這些系統服務一般叫作交叉業務，這是由於它們老是分佈在系統的不少組件中。經過將這些業務分佈在多個組件中，給咱們的代碼引入了雙重複雜性。

　　(1) 實現系統級業務的代碼在多個組件中複製。這意味着若是你要改變這些業務邏輯，你就必須到各個模塊去修改。就算把這些業務抽象成一個獨立模塊，其它模塊只是調用它的一個方法，可是這個方法調用也仍是分佈在不少地方。

　　(2) 組件會由於那些與本身核心業務無關的代碼變得雜亂。一個向地址錄中添加條目的方法應該只關心如何添加地址，而不是關心它是否是安全或支持事務的。

　　此時，咱們該怎麼辦呢？這正是AOP用得着的地方。AOP幫助咱們將這些服務模塊化，並把它們聲明式地應用在須要它們的地方，使得這些組件更加專一於自身業務，徹底不知道其它涉及到的系統服務。

　　這裏的概念切面，就是咱們要實現的交叉功能，是應用系統模塊化的一個方面或領域。切面的最多見例子就是日誌記錄。日誌記錄在系統中處處須要用到，利用繼承來重用日誌模塊是不合適的，這樣，就能夠建立一個日誌記錄切面，而且使用AOP在系統中應用。下圖展現了切面應用方式

圖表 1 應用切面

　　其中，通知Advice是切面的實際實現。鏈接點Joinpoint是應用程序執行過程當中插入切面的地點，這個地點能夠是方法調用，異常拋出，甚至能夠是要修改的字段，切面代碼在這些地方插入到你的應用流程中，添加新的行爲。切入點Pointcut定義了Advice應該應用在那些鏈接點，一般經過指定類名和方法名，或者匹配類名和方法名式樣的正則表達式來指定切入點。

　　2.2 AOP在Spring中的實現

　　基於AOP，業界存在各類各樣的AOP實現，好比，JBoss AOP、Spring AOP、ASPectJ、Aspect Werkz等。各自實現的功能也不同。AOP實現的強弱在很大程度上取決於鏈接點模型。目前，Spring只支持方法級的鏈接點。這和一些其餘AOP框架不同，如AspectJ和JBoss，它們還提供了屬性接入點，這樣能夠防止你建立特別細緻的通知，如對更新對象屬性值進行攔截。然而，因爲Spring關注於提供一個實現J2EE服務的框架，因此方法攔截能夠知足大部分要求，並且Spring的觀點是屬性攔截破壞了封裝，讓Advice觸發在屬性值改變而不是方法調用上無疑是破壞了這個概念。

　　Spring的AOP框架的關鍵點以下：

　　（1）Spring實現了AOP聯盟接口。在Spring AOP中，存在以下幾種通知（Advice）類型

　　Before通知：在目標方法被調用前調用，涉及接口org.springFramework.aop.MethodBeforeAdvice;

　　After通知：在目標方法被調用後調用，涉及接口爲org.springframework.aop.AfterReturningAdvice;

　　Throws通知：目標方法拋出異常時調用，涉及接口org.springframework.aop.MethodBeforeAdvice;

　　Around通知：攔截對目標對象方法調用，涉及接口爲org.aopalliance.intercept.MethodInterceptor。

　　（2）用Java編寫Spring通知，並在Spring的配置文件中，定義在什麼地方應用通知的切入點。

　　（3）Spring的運行時通知對象。代理Bean只有在第一次被應用系統須要的時候才被建立。若是你使用的是ApplicationContext，代理對象在BeanFactory載入全部Bean的時候被建立。Spring有兩種代理建立方式。若是目標對象實現了一個或多個接口暴露的方法，Spring將使用JDK的java.lang.reflect.Proxy類建立代理。這個類讓Spring動態產生一個新的類，它實現所需的接口，織入了通知，而且代理對目標對象的全部請求。若是目標對象沒有實現任何接口，Spring使用CGLIB庫生成目標對象的子類。在建立這個子類的時候，Spring將通知織入，而且將對目標對象的調用委託給這個子類。此時，須要將Spring發行包lib/cglib目錄下的JAR文件發佈到應用系統中。

　　2.3 Spring AOP的優點

　　藉助於Spring AOP，Spring IoC可以很方便的使用到很是健壯、靈活的企業級服務，是由於Spring AOP可以提供以下幾方面的優點：

　　（1）容許開發者使用聲明式企業服務，好比事務服務、安全性服務；EJB開發者都知道，EJB組件可以使用J2EE容器提供的聲明式服務，可是這些服務要藉助於EJB容器，而Spring AOP卻不須要EJB容器，藉助於Spring的事務抽象框架就能夠這些服務。

　　（2）開發者能夠開發知足業務需求的自定義切面；

　　（3）開發Spring AOP Advice很方便。由於這些AOP Advice僅是POJO類，藉助於Spring提供的ProxyFactoryBean,可以快速的搭建Spring AOP Advice。

　　三、結語

　　本文詳細闡述了Spring背後的IoC原理和AOP技術，以實際成功項目爲背景，抽取簡短片段，展現了Spring架構J2EE應用系統的原理。Spring IoC藉助於依賴注入機制，減輕了組件之間的依賴關係，同時也大大提升了組件的可移植性，組件獲得了更多的重用機會。藉助於Spring AOP，使得開發者能聲明式、基於元數據訪問企業級服務，AOP合理補充了OOP技術，Spring AOP合理地補充了Spring IoC容器。Spring IoC與Spring AOP組合，使得Spring成爲成功的J2EE架構框架，並能與標準的EJB等標準對抗，EJB再也不是必需品。Spring已經衝入了J2EE的核心，將引領整個J2EE開發、架構的方向。