在J2EE的整個(gè)發(fā)展歷程中，現在正是一個(gè)非常時(shí)刻。從很多方面來(lái)說(shuō)，J2EE都是一個(gè)偉大的成功：它成功地在從前沒(méi)有標準的地方建立了標準；大大提升了企業(yè)級軟件的開(kāi)放程度，并且得到了整個(gè)行業(yè)和開(kāi)發(fā)者的廣泛認可。然而，J2EE在一些方面已經(jīng)開(kāi)始捉襟見(jiàn)肘。J2EE應用開(kāi)發(fā)的成本通常很高。J2EE應用項目至少和從前的非J2EE項目一樣容易失敗——如果不是更容易失敗的話(huà)。這樣的失敗率高得讓人難以接受。在這樣的失敗率之下，軟件開(kāi)發(fā)幾乎變成了碰運氣。而在J2EE遭遇失敗的場(chǎng)景中，EJB通常都扮演著(zhù)重要的角色。因此，J2EE社群不斷地向著(zhù)更簡(jiǎn)單的解決方案、更少使用EJB的方向發(fā)展[1]。然而，每個(gè)應用程序都需要一些基礎設施，拒絕使用EJB并不意味著(zhù)拒絕EJB所采用的基礎設施解決方案。那么，如何利用現有的框架來(lái)提供這些基礎設施服務(wù)呢，伴隨著(zhù)這個(gè)問(wèn)題的提出，一個(gè)輕量級的J2EE解決方案出現了，這就是Spring Framework。
Spring是為簡(jiǎn)化企業(yè)級系統開(kāi)發(fā)而誕生的，Spring框架為J2EE應用常見(jiàn)的問(wèn)題提供了簡(jiǎn)單、有效的解決方案，使用Spring，你可以用簡(jiǎn)單的POJO(Plain Old Java Object)來(lái)實(shí)現那些以前只有EJB才能實(shí)現的功能。這樣不只是能簡(jiǎn)化服務(wù)器端開(kāi)發(fā)，任何Java系統開(kāi)發(fā)都能從Spring的簡(jiǎn)單、可測試和松耦合特征中受益?？梢院?jiǎn)單的說(shuō)，Spring是一個(gè)輕量級的反向控制（IoC）和面向切面編程（AOP）容器框架[3]。Spring IoC，借助于依賴(lài)注入設計模式，使得開(kāi)發(fā)者不用理會(huì )對象自身的生命周期及其關(guān)系，而且能夠改善開(kāi)發(fā)者對J2EE模式的使用；Spring AOP，借助于Spring實(shí)現的攔截器，開(kāi)發(fā)者能夠實(shí)現以聲明的方式使用企業(yè)級服務(wù)，比如安全性服務(wù)、事務(wù)服務(wù)等。Spring IoC和 Spring ; AOP組合，一起形成了Spring，這樣一個(gè)有機整體，使得構建輕量級的J2EE架構成為可能，而且事實(shí)證明，非常有效。沒(méi)有Spring IoC的Spring AOP是不完善的，沒(méi)有Spring AOP的Spring IoC是不健壯的。本文是以Spring架構的成功的實(shí)際商務(wù)系統項目為背景，闡述了反向控制原理和面向切面的編程技術(shù)在Spring框架中的應用，同時(shí)抽取適量代碼示意具體應用，并和傳統開(kāi)發(fā)模式進(jìn)行對比，展示了Spring framework的簡(jiǎn)單，高效，可維護等優(yōu)點(diǎn)。
1、Spring IoC 1.1 反向控制原理
反向控制是Spring框架的核心。但是，反向控制是什么意思？到底控制的什么方面被反向了呢？2004年美國專(zhuān)家Martin Fowler發(fā)表了一篇論文《Inversion of Control Containers and the Dependency Injection pattern》闡述了這個(gè)問(wèn)題，他總結說(shuō)是獲得依賴(lài)對象的方式反向了，根據這個(gè)啟示，他還為反向控制提出了一個(gè)更貼切的名字：Dependency Injection(DI 依賴(lài)注入)。
通常，應用代碼需要告知容器或框架,讓它們找到自身所需要的類(lèi),然后再由應用代碼創(chuàng )建待使用的對象實(shí)例。因此，應用代碼在使用實(shí)例之前，需要創(chuàng )建對象實(shí)例。然而，IoC模式中,創(chuàng )建對象實(shí)例的任務(wù)交給IoC容器或框架(實(shí)現了IoC設計模式的框架也被稱(chēng)為IoC容器)，使得應用代碼只需要直接使用實(shí)例，這就是IoC。相對IoC 而言，“依賴(lài)注入”的確更加準確的描述了這種設計理念。所謂依賴(lài)注入，即組件之間的依賴(lài)關(guān)系由容器在運行期決定，形象的來(lái)說(shuō)，即由容器動(dòng)態(tài)的將某種依賴(lài)關(guān)系注入到組件之中。
1.2 IoC在Spring中的實(shí)現
任何重要的系統都需要至少兩個(gè)相互合作的類(lèi)來(lái)完成業(yè)務(wù)邏輯。通常，每個(gè)對象都要自己負責得到它的合作（依賴(lài)）對象。你會(huì )發(fā)現，這樣會(huì )導致代碼耦合度高而且難于測試。使用IoC，對象的依賴(lài)都是在對象創(chuàng )建時(shí)由負責協(xié)調系統中各個(gè)對象的外部實(shí)體提供的，這樣使軟件組件松散連接成為可能。下面示意了Spring IoC 應用，步驟如下：
?。?）定義Action接口，并為其定義一個(gè)execute方法，以完成目標邏輯。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一書(shū)中提出“Programming to an Interface，not an implementation”的原則，這里首先將業(yè)務(wù)對象抽象成接口，正是為了實(shí)施這個(gè)原則。
?。?）類(lèi)UpperAction實(shí)現Action接口，在此類(lèi)中，定義一個(gè)String型的域message，并提供相應的setter和getter方法，實(shí)現的execute方法如下：
| public String execute (String str) {
return (getMessage () + str).toUpperCase () ; } |
?。?）編寫(xiě)Spring配置文件（bean.XML）
| ＜beans＞
＜bean id="TheAction" class="net.chen.spring.qs.UpperAction"＞ ＜property name="message"＞ ＜value＞HeLLo＜/value＞ ＜/property＞ ＜/bean＞ ＜/beans＞ |
?。?）測試代碼
| public void testQuickStart () {
ApplicationContext ctx=new FileSystemXmlApplicationContext ("bean.xml"); Action a= (Action) ctx.getBean ("TheAction"); System.out.println (a. execute ("Rod Johnson")); } |
上面的測試代碼中，我們根據"bean.xml"創(chuàng )建了一個(gè)ApplicationContext實(shí)例，并從此實(shí)例中獲取我們所需的Action實(shí)現，運行測試代碼，我們看到控制臺輸出：
| ……
HELLO ROD JOHNSON |
仔細觀(guān)察一下上面的代碼，可以看到：
?。?）我們的組件并不需要實(shí)現框架指定的接口，因此可以輕松的將組件從Spring中脫離，甚至不需要任何修改，這在基于EJB框架實(shí)現的應用中是難以想象的。
?。?）組件間的依賴(lài)關(guān)系減少，極大改善了代碼的可重用性。Spring的依賴(lài)注入機制，可以在運行期為組件配置所需資源，而無(wú)需在編寫(xiě)組件代碼時(shí)就加以指定，從而在相當程度上降低了組件之間的耦合。
Spring給我們帶來(lái)了如此這般的好處，那么，反過(guò)來(lái)，讓我們試想一下，如果不使用Spring框架，回到我們傳統的編碼模式，情況會(huì )是怎樣呢？
首先，我們必須編寫(xiě)一個(gè)配置文件讀取類(lèi)，以實(shí)現Message屬性的可配置化。
其次，得有一個(gè)Factory模式的實(shí)現，并結合配置文件的讀寫(xiě)完成Action的動(dòng)態(tài)加載。于是，我們實(shí)現了一個(gè)ActionFactory來(lái)實(shí)現這個(gè)功能：
| 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 |
測試代碼也作相應修改?，F在不論實(shí)現的好壞，總之通過(guò)上面新增的多行代碼，終于實(shí)現了類(lèi)似的功能。如果現在有了一個(gè)新的需求，這樣這個(gè)ActionFactory每次都新建一個(gè)類(lèi)的實(shí)例，顯然這對系統性能不利，考慮到我們的兩個(gè)Action都是線(xiàn)程安全的，修改一下ActionFactory，保持系統中只有一個(gè)Action實(shí)例供其它線(xiàn)程調用。另外Action對象創(chuàng )建后，需要做一些初始化工作。修改一下ActionFactory，使其在創(chuàng )建Action實(shí)例之后，隨即就調用Action.init方法執行初始化。Action的處理這樣就差不多了。下面我們來(lái)看看另外一個(gè)Factory
……
往往這些系統開(kāi)發(fā)中最常見(jiàn)的需求，會(huì )導致我們的代碼迅速膨脹，而Spring IoC的出現，則大大緩解了這樣的窘境。通過(guò)以上實(shí)例，可以看出，Spring IoC為我們提供了如下幾方面的優(yōu)勢：
?。?）應用組件不需要在運行時(shí)尋找其協(xié)作者，因此更易于開(kāi)發(fā)和編寫(xiě)應用；
?。?）由于借助于IoC容器管理組件的依賴(lài)關(guān)系，使得應用的單元測試和集成測試更利于展開(kāi)；
?。?）通常，在借助于IoC容器關(guān)系業(yè)務(wù)對象的前提下，很少需要使用具體IoC容器提供的API，這使得集成現有的遺留應用成為可能。
因此，通過(guò)使用IoC能夠降低組件之間的耦合度，最終，能夠提高類(lèi)的重用性，利于測試，而且更利于整個(gè)產(chǎn)品或系統集成和配置。
2、Spring AOP
2.1 面向切面編程基礎
通常，系統由很多組件組成，每個(gè)組件負責一部分功能，然而，這些組件也經(jīng)常帶有一些除了核心功能之外的附帶功能 。系統服務(wù)如日志、事務(wù)管理和安全經(jīng)常融入到一些其他功能模塊中。這些系統服務(wù)通常叫做交叉業(yè)務(wù)，這是因為它們總是分布在系統的很多組件中。通過(guò)將這些業(yè)務(wù)分布在多個(gè)組件中，給我們的代碼引入了雙重復雜性。
(1) 實(shí)現系統級業(yè)務(wù)的代碼在多個(gè)組件中復制。這意味著(zhù)如果你要改變這些業(yè)務(wù)邏輯，你就必須到各個(gè)模塊去修改。就算把這些業(yè)務(wù)抽象成一個(gè)獨立模塊，其它模塊只是調用它的一個(gè)方法，但是這個(gè)方法調用也還是分布在很多地方。
(2) 組件會(huì )因為那些與自己核心業(yè)務(wù)無(wú)關(guān)的代碼變得雜亂。一個(gè)向地址錄中添加條目的方法應該只關(guān)心如何添加地址，而不是關(guān)心它是不是安全或支持事務(wù)的。
此時(shí)，我們該怎么辦呢？這正是AOP用得著(zhù)的地方。AOP幫助我們將這些服務(wù)模塊化，并把它們聲明式地應用在需要它們的地方，使得這些組件更加專(zhuān)注于自身業(yè)務(wù)，完全不知道其它涉及到的系統服務(wù)。
這里的概念切面，就是我們要實(shí)現的交叉功能，是應用系統模塊化的一個(gè)方面或領(lǐng)域。切面的最常見(jiàn)例子就是日志記錄。日志記錄在系統中到處需要用到，利用繼承來(lái)重用日志模塊是不合適的，這樣，就可以創(chuàng )建一個(gè)日志記錄切面，并且使用AOP在系統中應用。下圖展示了切面應用方式
圖表 1 應用切面
其中，通知Advice是切面的實(shí)際實(shí)現。連接點(diǎn)Joinpoint是應用程序執行過(guò)程中插入切面的地點(diǎn)，這個(gè)地點(diǎn)可以是方法調用，異常拋出，甚至可以是要修改的字段，切面代碼在這些地方插入到你的應用流程中，添加新的行為。切入點(diǎn)Pointcut定義了Advice應該應用在那些連接點(diǎn)，通常通過(guò)指定類(lèi)名和方法名，或者匹配類(lèi)名和方法名式樣的正則表達式來(lái)指定切入點(diǎn)。
2.2 AOP在Spring中的實(shí)現
基于A(yíng)OP，業(yè)界存在各種各樣的AOP實(shí)現，比如，JBoss AOP、Spring AOP、ASPectJ、Aspect Werkz等。各自實(shí)現的功能也不一樣。AOP實(shí)現的強弱在很大程度上取決于連接點(diǎn)模型。目前，Spring只支持方法級的連接點(diǎn)。這和一些其他AOP框架不一樣，如AspectJ和JBoss，它們還提供了屬性接入點(diǎn)，這樣可以防止你創(chuàng )建特別細致的通知，如對更新對象屬性值進(jìn)行攔截。然而，由于Spring關(guān)注于提供一個(gè)實(shí)現J2EE服務(wù)的框架，所以方法攔截可以滿(mǎn)足大部分要求，而且Spring的觀(guān)點(diǎn)是屬性攔截破壞了封裝，讓Advice觸發(fā)在屬性值改變而不是方法調用上無(wú)疑是破壞了這個(gè)概念。
Spring的AOP框架的關(guān)鍵點(diǎn)如下：
?。?）Spring實(shí)現了AOP聯(lián)盟接口。在Spring AOP中，存在如下幾種通知（Advice）類(lèi)型
Before通知：在目標方法被調用前調用，涉及接口org.springFramework.aop.MethodBeforeAdvice;
After通知：在目標方法被調用后調用，涉及接口為org.springframework.aop.AfterReturningAdvice;
Throws通知：目標方法拋出異常時(shí)調用，涉及接口org.springframework.aop.MethodBeforeAdvice;
Around通知：攔截對目標對象方法調用，涉及接口為org.aopalliance.intercept.MethodInterceptor。
?。?）用Java編寫(xiě)Spring通知，并在Spring的配置文件中，定義在什么地方應用通知的切入點(diǎn)。
?。?）Spring的運行時(shí)通知對象。代理Bean只有在第一次被應用系統需要的時(shí)候才被創(chuàng )建。如果你使用的是ApplicationContext，代理對象在BeanFactory載入所有Bean的時(shí)候被創(chuàng )建。Spring有兩種代理創(chuàng )建方式。如果目標對象實(shí)現了一個(gè)或多個(gè)接口暴露的方法，Spring將使用JDK的java.lang.reflect.Proxy類(lèi)創(chuàng )建代理。這個(gè)類(lèi)讓Spring動(dòng)態(tài)產(chǎn)生一個(gè)新的類(lèi)，它實(shí)現所需的接口，織入了通知，并且代理對目標對象的所有請求。如果目標對象沒(méi)有實(shí)現任何接口，Spring使用CGLIB庫生成目標對象的子類(lèi)。在創(chuàng )建這個(gè)子類(lèi)的時(shí)候，Spring將通知織入，并且將對目標對象的調用委托給這個(gè)子類(lèi)。此時(shí)，需要將Spring發(fā)行包lib/cglib目錄下的JAR文件發(fā)布到應用系統中。
2.3 Spring AOP的優(yōu)勢
借助于Spring AOP，Spring IoC能夠很方便的使用到非常健壯、靈活的企業(yè)級服務(wù)，是因為Spring AOP能夠提供如下幾方面的優(yōu)勢：
?。?）允許開(kāi)發(fā)者使用聲明式企業(yè)服務(wù)，比如事務(wù)服務(wù)、安全性服務(wù)；EJB開(kāi)發(fā)者都知道，EJB組件能夠使用J2EE容器提供的聲明式服務(wù)，但是這些服務(wù)要借助于EJB容器，而Spring AOP卻不需要EJB容器，借助于Spring的事務(wù)抽象框架就可以這些服務(wù)。
?。?）開(kāi)發(fā)者可以開(kāi)發(fā)滿(mǎn)足業(yè)務(wù)需求的自定義切面；
?。?）開(kāi)發(fā)Spring AOP Advice很方便。因為這些AOP Advice僅是POJO類(lèi)，借助于Spring提供的ProxyFactoryBean,能夠快速的搭建Spring AOP Advice。
3、結語(yǔ)
本文詳細闡述了Spring背后的IoC原理和AOP技術(shù)，以實(shí)際成功項目為背景，抽取簡(jiǎn)短片斷，展示了Spring架構J2EE應用系統的原理。Spring IoC借助于依賴(lài)注入機制，減輕了組件之間的依賴(lài)關(guān)系，同時(shí)也大大提高了組件的可移植性，組件得到了更多的重用機會(huì )。借助于Spring AOP，使得開(kāi)發(fā)者能聲明式、基于元數據訪(fǎng)問(wèn)企業(yè)級服務(wù)，AOP合理補充了OOP技術(shù)，Spring AOP合理地補充了Spring IoC容器。Spring IoC與Spring AOP組合，使得Spring成為成功的J2EE架構框架，并能與標準的EJB等標準對抗，EJB不再是必需品。Spring已經(jīng)沖入了J2EE的核心，將引領(lǐng)整個(gè)J2EE開(kāi)發(fā)、架構的方向。
聯(lián)系客服
