針對(duì)傳統(tǒng)的J2EE架構(gòu)方案常常無(wú)法讓人滿意：程序過(guò)于復(fù)雜，難以測(cè)試和維護(hù)成本高。根據(jù)企業(yè)實(shí)際需求，本文探討了一種輕量級(jí)的J2EE應(yīng)用框架Spring ，它用更加輕量、更加靈活的基礎(chǔ)設(shè)施取代了EJB。在此對(duì)Spring背后的反向控制原理和面向切面編程技術(shù)進(jìn)行了比較深入研究，并與傳統(tǒng)實(shí)現(xiàn)進(jìn)行對(duì)比，顯示了這種框架具有大大降低開發(fā)成本，可測(cè)試等優(yōu)點(diǎn)。
關(guān)鍵詞 Spring；反向控制；面向切面編程；POJO；依賴注入
引言 在J2EE的整個(gè)發(fā)展歷程中，現(xiàn)在正是一個(gè)非常時(shí)刻。從很多方面來(lái)說(shuō)，J2EE都是一個(gè)偉大的成功：它成功地在從前沒(méi)有標(biāo)準(zhǔn)的地方建立了標(biāo)準(zhǔn)；大大提升了企業(yè)級(jí)軟件的開放程度，并且得到了整個(gè)行業(yè)和開發(fā)者的廣泛認(rèn)可。然而，J2EE在一些方面已經(jīng)開始捉襟見肘。J2EE應(yīng)用開發(fā)的成本通常很高。J2EE應(yīng)用項(xiàng)目至少和從前的非J2EE項(xiàng)目一樣容易失敗——如果不是更容易失敗的話。這樣的失敗率高得讓人難以接受。在這樣的失敗率之下，軟件開發(fā)幾乎變成了碰運(yùn)氣。而在J2EE遭遇失敗的場(chǎng)景中，EJB通常都扮演著重要的角色。因此，J2EE社群不斷地向著更簡(jiǎn)單的解決方案、更少使用EJB的方向發(fā)展
[1]。然而，每個(gè)應(yīng)用程序都需要一些基礎(chǔ)設(shè)施，拒絕使用EJB并不意味著拒絕EJB所采用的基礎(chǔ)設(shè)施解決方案。那么，如何利用現(xiàn)有的框架來(lái)提供這些基礎(chǔ)設(shè)施服務(wù)呢，伴隨著這個(gè)問(wèn)題的提出，一個(gè)輕量級(jí)的J2EE解決方案出現(xiàn)了，這就是Spring Framework。
Spring是為簡(jiǎn)化企業(yè)級(jí)系統(tǒng)開發(fā)而誕生的，Spring框架為J2EE應(yīng)用常見的問(wèn)題提供了簡(jiǎn)單、有效的解決方案，使用Spring，你可以用簡(jiǎn)單的POJO(Plain Old Java Object)來(lái)實(shí)現(xiàn)那些以前只有EJB才能實(shí)現(xiàn)的功能。這樣不只是能簡(jiǎn)化服務(wù)器端開發(fā)，任何Java系統(tǒng)開發(fā)都能從Spring的簡(jiǎn)單、可測(cè)試和松耦合特征中受益。可以簡(jiǎn)單的說(shuō)，Spring是一個(gè)輕量級(jí)的反向控制（IoC）和面向切面編程（AOP）容器框架
[3]。Spring IoC，借助于依賴注入設(shè)計(jì)模式，使得開發(fā)者不用理會(huì)對(duì)象自身的生命周期及其關(guān)系，而且能夠改善開發(fā)者對(duì)J2EE模式的使用；Spring AOP，借助于Spring實(shí)現(xiàn)的攔截器，開發(fā)者能夠?qū)崿F(xiàn)以聲明的方式使用企業(yè)級(jí)服務(wù)，比如安全性服務(wù)、事務(wù)服務(wù)等。Spring IoC和 Spring ; AOP組合，一起形成了Spring，這樣一個(gè)有機(jī)整體，使得構(gòu)建輕量級(jí)的J2EE架構(gòu)成為可能，而且事實(shí)證明，非常有效。沒(méi)有Spring IoC的Spring AOP是不完善的，沒(méi)有Spring AOP的Spring IoC是不健壯的。本文是以Spring架構(gòu)的成功的實(shí)際商務(wù)系統(tǒng)項(xiàng)目為背景，闡述了反向控制原理和面向切面的編程技術(shù)在Spring框架中的應(yīng)用，同時(shí)抽取適量代碼示意具體應(yīng)用，并和傳統(tǒng)開發(fā)模式進(jìn)行對(duì)比，展示了Spring framework的簡(jiǎn)單，高效，可維護(hù)等優(yōu)點(diǎn)。
1、Spring IoC 1.1 反向控制原理 反向控制是Spring框架的核心。但是，反向控制是什么意思？到底控制的什么方面被反向了呢？2004年美國(guó)專家Martin Fowler發(fā)表了一篇論文《Inversion of Control Containers and the Dependency Injection pattern》闡述了這個(gè)問(wèn)題，他總結(jié)說(shuō)是獲得依賴對(duì)象的方式反向了，根據(jù)這個(gè)啟示，他還為反向控制提出了一個(gè)更貼切的名字：Dependency Injection(DI 依賴注入)。
通常，應(yīng)用代碼需要告知容器或框架,讓它們找到自身所需要的類,然后再由應(yīng)用代碼創(chuàng)建待使用的對(duì)象實(shí)例。因此，應(yīng)用代碼在使用實(shí)例之前，需要?jiǎng)?chuàng)建對(duì)象實(shí)例。然而，IoC模式中,創(chuàng)建對(duì)象實(shí)例的任務(wù)交給IoC容器或框架(實(shí)現(xiàn)了IoC設(shè)計(jì)模式的框架也被稱為IoC容器)，使得應(yīng)用代碼只需要直接使用實(shí)例，這就是IoC。相對(duì)IoC 而言，“依賴注入”的確更加準(zhǔn)確的描述了這種設(shè)計(jì)理念。所謂依賴注入，即組件之間的依賴關(guān)系由容器在運(yùn)行期決定，形象的來(lái)說(shuō)，即由容器動(dòng)態(tài)的將某種依賴關(guān)系注入到組件之中。
1.2 IoC在Spring中的實(shí)現(xiàn)
任何重要的系統(tǒng)都需要至少兩個(gè)相互合作的類來(lái)完成業(yè)務(wù)邏輯。通常，每個(gè)對(duì)象都要自己負(fù)責(zé)得到它的合作（依賴）對(duì)象。你會(huì)發(fā)現(xiàn)，這樣會(huì)導(dǎo)致代碼耦合度高而且難于測(cè)試。使用IoC，對(duì)象的依賴都是在對(duì)象創(chuàng)建時(shí)由負(fù)責(zé)協(xié)調(diào)系統(tǒng)中各個(gè)對(duì)象的外部實(shí)體提供的，這樣使軟件組件松散連接成為可能。下面示意了Spring IoC 應(yīng)用，步驟如下：
（1）定義Action接口，并為其定義一個(gè)execute方法，以完成目標(biāo)邏輯。多年前，GoF在《Design Pattern：Elements of Reusable Object-Oriented Software》一書中提出“Programming to an Interface，not an implementation”的原則，這里首先將業(yè)務(wù)對(duì)象抽象成接口，正是為了實(shí)施這個(gè)原則。
（2）類UpperAction實(shí)現(xiàn)Action接口，在此類中，定義一個(gè)String型的域message，并提供相應(yīng)的setter和getter方法，實(shí)現(xiàn)的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）測(cè)試代碼
public void testQuickStart () {
ApplicationContext ctx=new
FileSystemXmlApplicationContext ("bean.xml");
Action a= (Action) ctx.getBean ("TheAction");
System.out.println (a. execute ("Rod Johnson"));
} |
上面的測(cè)試代碼中，我們根據(jù)"bean.xml"創(chuàng)建了一個(gè)ApplicationContext實(shí)例，并從此實(shí)例中獲取我們所需的Action實(shí)現(xiàn)，運(yùn)行測(cè)試代碼，我們看到控制臺(tái)輸出：
仔細(xì)觀察一下上面的代碼，可以看到：
（1）我們的組件并不需要實(shí)現(xiàn)框架指定的接口，因此可以輕松的將組件從Spring中脫離，甚至不需要任何修改，這在基于EJB框架實(shí)現(xiàn)的應(yīng)用中是難以想象的。
（2）組件間的依賴關(guān)系減少，極大改善了代碼的可重用性。Spring的依賴注入機(jī)制，可以在運(yùn)行期為組件配置所需資源，而無(wú)需在編寫組件代碼時(shí)就加以指定，從而在相當(dāng)程度上降低了組件之間的耦合。
Spring給我們帶來(lái)了如此這般的好處，那么，反過(guò)來(lái)，讓我們?cè)囅胍幌拢绻皇褂肧pring框架，回到我們傳統(tǒng)的編碼模式，情況會(huì)是怎樣呢？
首先，我們必須編寫一個(gè)配置文件讀取類，以實(shí)現(xiàn)Message屬性的可配置化。
其次，得有一個(gè)Factory模式的實(shí)現(xiàn)，并結(jié)合配置文件的讀寫完成Action的動(dòng)態(tài)加載。于是，我們實(shí)現(xiàn)了一個(gè)ActionFactory來(lái)實(shí)現(xiàn)這個(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 |
測(cè)試代碼也作相應(yīng)修改。現(xiàn)在不論實(shí)現(xiàn)的好壞，總之通過(guò)上面新增的多行代碼，終于實(shí)現(xiàn)了類似的功能。如果現(xiàn)在有了一個(gè)新的需求，這樣這個(gè)ActionFactory每次都新建一個(gè)類的實(shí)例，顯然這對(duì)系統(tǒng)性能不利，考慮到我們的兩個(gè)Action都是線程安全的，修改一下ActionFactory，保持系統(tǒng)中只有一個(gè)Action實(shí)例供其它線程調(diào)用。另外Action對(duì)象創(chuàng)建后，需要做一些初始化工作。修改一下ActionFactory，使其在創(chuàng)建Action實(shí)例之后，隨即就調(diào)用Action.init方法執(zhí)行初始化。Action的處理這樣就差不多了。下面我們來(lái)看看另外一個(gè)Factory
……
往往這些系統(tǒng)開發(fā)中最常見的需求，會(huì)導(dǎo)致我們的代碼迅速膨脹，而Spring IoC的出現(xiàn)，則大大緩解了這樣的窘境。通過(guò)以上實(shí)例，可以看出，Spring IoC為我們提供了如下幾方面的優(yōu)勢(shì)：
（1）應(yīng)用組件不需要在運(yùn)行時(shí)尋找其協(xié)作者，因此更易于開發(fā)和編寫應(yīng)用；
（2）由于借助于IoC容器管理組件的依賴關(guān)系，使得應(yīng)用的單元測(cè)試和集成測(cè)試更利于展開；
（3）通常，在借助于IoC容器關(guān)系業(yè)務(wù)對(duì)象的前提下，很少需要使用具體IoC容器提供的API，這使得集成現(xiàn)有的遺留應(yīng)用成為可能。
因此，通過(guò)使用IoC能夠降低組件之間的耦合度，最終，能夠提高類的重用性，利于測(cè)試，而且更利于整個(gè)產(chǎn)品或系統(tǒng)集成和配置。