• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Shuffy

            不斷的學(xué)習(xí),不斷的思考,才能不斷的進(jìn)步.Let's do better together!
            posts - 102, comments - 43, trackbacks - 0, articles - 19

            反向控制和面向切面編程在Spring的應(yīng)用

            Posted on 2011-10-18 00:20 Shuffy 閱讀(466) 評論(0)  編輯 收藏 引用 所屬分類: Java

            反向控制和面向切面編程在Spring的應(yīng)用


            摘 要 針對傳統(tǒng)的J2EE架構(gòu)方案常常無法讓人滿意:程序過于復(fù)雜,難以測試和維護(hù)成本高。根據(jù)企業(yè)實際需求,本文探討了一種輕量級的J2EE應(yīng)用框架Spring ,它用更加輕量、更加靈活的基礎(chǔ)設(shè)施取代了EJB。在此對Spring背后的反向控制原理和面向切面編程技術(shù)進(jìn)行了比較深入研究,并與傳統(tǒng)實現(xiàn)進(jìn)行對比,顯示了這種框架具有大大降低開發(fā)成本,可測試等優(yōu)點(diǎn)。

              關(guān)鍵詞 Spring;反向控制;面向切面編程;POJO;依賴注入

              引言

              在J2EE的整個發(fā)展歷程中,現(xiàn)在正是一個非常時刻。從很多方面來說,J2EE都是一個偉大的成功:它成功地在從前沒有標(biāo)準(zhǔn)的地方建立了標(biāo)準(zhǔn);大大提升了企業(yè)級軟件的開放程度,并且得到了整個行業(yè)和開發(fā)者的廣泛認(rèn)可。然而,J2EE在一些方面已經(jīng)開始捉襟見肘。J2EE應(yīng)用開發(fā)的成本通常很高。J2EE應(yīng)用項目至少和從前的非J2EE項目一樣容易失敗——如果不是更容易失敗的話。這樣的失敗率高得讓人難以接受。在這樣的失敗率之下,軟件開發(fā)幾乎變成了碰運(yùn)氣。而在J2EE遭遇失敗的場景中,EJB通常都扮演著重要的角色。因此,J2EE社群不斷地向著更簡單的解決方案、更少使用EJB的方向發(fā)展[1]。然而,每個應(yīng)用程序都需要一些基礎(chǔ)設(shè)施,拒絕使用EJB并不意味著拒絕EJB所采用的基礎(chǔ)設(shè)施解決方案。那么,如何利用現(xiàn)有的框架來提供這些基礎(chǔ)設(shè)施服務(wù)呢,伴隨著這個問題的提出,一個輕量級的J2EE解決方案出現(xiàn)了,這就是Spring Framework。

              Spring是為簡化企業(yè)級系統(tǒng)開發(fā)而誕生的,Spring框架為J2EE應(yīng)用常見的問題提供了簡單、有效的解決方案,使用Spring,你可以用簡單的POJO(Plain Old Java Object)來實現(xiàn)那些以前只有EJB才能實現(xiàn)的功能。這樣不只是能簡化服務(wù)器端開發(fā),任何Java系統(tǒng)開發(fā)都能從Spring的簡單、可測試和松耦合特征中受益。可以簡單的說,Spring是一個輕量級的反向控制(IoC)和面向切面編程(AOP)容器框架[3]。Spring IoC,借助于依賴注入設(shè)計模式,使得開發(fā)者不用理會對象自身的生命周期及其關(guān)系,而且能夠改善開發(fā)者對J2EE模式的使用;Spring AOP,借助于Spring實現(xiàn)的攔截器,開發(fā)者能夠?qū)崿F(xiàn)以聲明的方式使用企業(yè)級服務(wù),比如安全性服務(wù)、事務(wù)服務(wù)等。Spring IoC和 Spring ; AOP組合,一起形成了Spring,這樣一個有機(jī)整體,使得構(gòu)建輕量級的J2EE架構(gòu)成為可能,而且事實證明,非常有效。沒有Spring IoC的Spring AOP是不完善的,沒有Spring AOP的Spring IoC是不健壯的。本文是以Spring架構(gòu)的成功的實際商務(wù)系統(tǒng)項目為背景,闡述了反向控制原理和面向切面的編程技術(shù)在Spring框架中的應(yīng)用,同時抽取適量代碼示意具體應(yīng)用,并和傳統(tǒng)開發(fā)模式進(jìn)行對比,展示了Spring framework的簡單,高效,可維護(hù)等優(yōu)點(diǎn)。

              1、Spring IoC 1.1 反向控制原理

              反向控制是Spring框架的核心。但是,反向控制是什么意思?到底控制的什么方面被反向了呢?2004年美國專家Martin Fowler發(fā)表了一篇論文《Inversion of Control Containers and the Dependency Injection pattern》闡述了這個問題,他總結(jié)說是獲得依賴對象的方式反向了,根據(jù)這個啟示,他還為反向控制提出了一個更貼切的名字:Dependency Injection(DI 依賴注入)。

              通常,應(yīng)用代碼需要告知容器或框架,讓它們找到自身所需要的類,然后再由應(yīng)用代碼創(chuàng)建待使用的對象實例。因此,應(yīng)用代碼在使用實例之前,需要創(chuàng)建對象實例。然而,IoC模式中,創(chuàng)建對象實例的任務(wù)交給IoC容器或框架(實現(xiàn)了IoC設(shè)計模式的框架也被稱為IoC容器),使得應(yīng)用代碼只需要直接使用實例,這就是IoC。相對IoC 而言,“依賴注入”的確更加準(zhǔn)確的描述了這種設(shè)計理念。所謂依賴注入,即組件之間的依賴關(guān)系由容器在運(yùn)行期決定,形象的來說,即由容器動態(tài)的將某種依賴關(guān)系注入到組件之中。

              1.2 IoC在Spring中的實現(xiàn)

              任何重要的系統(tǒng)都需要至少兩個相互合作的類來完成業(yè)務(wù)邏輯。通常,每個對象都要自己負(fù)責(zé)得到它的合作(依賴)對象。你會發(fā)現(xiàn),這樣會導(dǎo)致代碼耦合度高而且難于測試。使用IoC,對象的依賴都是在對象創(chuàng)建時由負(fù)責(zé)協(xié)調(diào)系統(tǒng)中各個對象的外部實體提供的,這樣使軟件組件松散連接成為可能。下面示意了Spring IoC 應(yīng)用,步驟如下:

              (1)定義Action接口,并為其定義一個execute方法,以完成目標(biāo)邏輯。多年前,GoF在《Design Pattern:Elements of Reusable Object-Oriented Software》一書中提出“Programming to an Interface,not an implementation”的原則,這里首先將業(yè)務(wù)對象抽象成接口,正是為了實施這個原則。

              (2)類UpperAction實現(xiàn)Action接口,在此類中,定義一個String型的域message,并提供相應(yīng)的setter和getter方法,實現(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)測試代碼

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

              上面的測試代碼中,我們根據(jù)"bean.xml"創(chuàng)建了一個ApplicationContext實例,并從此實例中獲取我們所需的Action實現(xiàn),運(yùn)行測試代碼,我們看到控制臺輸出:

            ……
            HELLO ROD JOHNSON

              仔細(xì)觀察一下上面的代碼,可以看到:

              (1)我們的組件并不需要實現(xiàn)框架指定的接口,因此可以輕松的將組件從Spring中脫離,甚至不需要任何修改,這在基于EJB框架實現(xiàn)的應(yīng)用中是難以想象的。

              (2)組件間的依賴關(guān)系減少,極大改善了代碼的可重用性。Spring的依賴注入機(jī)制,可以在運(yùn)行期為組件配置所需資源,而無需在編寫組件代碼時就加以指定,從而在相當(dāng)程度上降低了組件之間的耦合。

              Spring給我們帶來了如此這般的好處,那么,反過來,讓我們試想一下,如果不使用Spring框架,回到我們傳統(tǒng)的編碼模式,情況會是怎樣呢?

              首先,我們必須編寫一個配置文件讀取類,以實現(xiàn)Message屬性的可配置化。

              其次,得有一個Factory模式的實現(xiàn),并結(jié)合配置文件的讀寫完成Action的動態(tài)加載。于是,我們實現(xiàn)了一個ActionFactory來實現(xiàn)這個功能:

            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

              測試代碼也作相應(yīng)修改。現(xiàn)在不論實現(xiàn)的好壞,總之通過上面新增的多行代碼,終于實現(xiàn)了類似的功能。如果現(xiàn)在有了一個新的需求,這樣這個ActionFactory每次都新建一個類的實例,顯然這對系統(tǒng)性能不利,考慮到我們的兩個Action都是線程安全的,修改一下ActionFactory,保持系統(tǒng)中只有一個Action實例供其它線程調(diào)用。另外Action對象創(chuàng)建后,需要做一些初始化工作。修改一下ActionFactory,使其在創(chuàng)建Action實例之后,隨即就調(diào)用Action.init方法執(zhí)行初始化。Action的處理這樣就差不多了。下面我們來看看另外一個Factory

              ……

              往往這些系統(tǒng)開發(fā)中最常見的需求,會導(dǎo)致我們的代碼迅速膨脹,而Spring IoC的出現(xiàn),則大大緩解了這樣的窘境。通過以上實例,可以看出,Spring IoC為我們提供了如下幾方面的優(yōu)勢:

              (1)應(yīng)用組件不需要在運(yùn)行時尋找其協(xié)作者,因此更易于開發(fā)和編寫應(yīng)用;

              (2)由于借助于IoC容器管理組件的依賴關(guān)系,使得應(yīng)用的單元測試和集成測試更利于展開;

              (3)通常,在借助于IoC容器關(guān)系業(yè)務(wù)對象的前提下,很少需要使用具體IoC容器提供的API,這使得集成現(xiàn)有的遺留應(yīng)用成為可能。

              因此,通過使用IoC能夠降低組件之間的耦合度,最終,能夠提高類的重用性,利于測試,而且更利于整個產(chǎn)品或系統(tǒng)集成和配置。


              2、Spring AOP

              2.1 面向切面編程基礎(chǔ)

              通常,系統(tǒng)由很多組件組成,每個組件負(fù)責(zé)一部分功能,然而,這些組件也經(jīng)常帶有一些除了核心功能之外的附帶功能 。系統(tǒng)服務(wù)如日志、事務(wù)管理和安全經(jīng)常融入到一些其他功能模塊中。這些系統(tǒng)服務(wù)通常叫做交叉業(yè)務(wù),這是因為它們總是分布在系統(tǒng)的很多組件中。通過將這些業(yè)務(wù)分布在多個組件中,給我們的代碼引入了雙重復(fù)雜性。

              (1) 實現(xiàn)系統(tǒng)級業(yè)務(wù)的代碼在多個組件中復(fù)制。這意味著如果你要改變這些業(yè)務(wù)邏輯,你就必須到各個模塊去修改。就算把這些業(yè)務(wù)抽象成一個獨(dú)立模塊,其它模塊只是調(diào)用它的一個方法,但是這個方法調(diào)用也還是分布在很多地方。

              (2) 組件會因為那些與自己核心業(yè)務(wù)無關(guān)的代碼變得雜亂。一個向地址錄中添加條目的方法應(yīng)該只關(guān)心如何添加地址,而不是關(guān)心它是不是安全或支持事務(wù)的。

              此時,我們該怎么辦呢?這正是AOP用得著的地方。AOP幫助我們將這些服務(wù)模塊化,并把它們聲明式地應(yīng)用在需要它們的地方,使得這些組件更加專注于自身業(yè)務(wù),完全不知道其它涉及到的系統(tǒng)服務(wù)。

              這里的概念切面,就是我們要實現(xiàn)的交叉功能,是應(yīng)用系統(tǒng)模塊化的一個方面或領(lǐng)域。切面的最常見例子就是日志記錄。日志記錄在系統(tǒng)中到處需要用到,利用繼承來重用日志模塊是不合適的,這樣,就可以創(chuàng)建一個日志記錄切面,并且使用AOP在系統(tǒng)中應(yīng)用。下圖展示了切面應(yīng)用方式


                                 圖表 1 應(yīng)用切面

              其中,通知Advice是切面的實際實現(xiàn)。連接點(diǎn)Joinpoint是應(yīng)用程序執(zhí)行過程中插入切面的地點(diǎn),這個地點(diǎn)可以是方法調(diào)用,異常拋出,甚至可以是要修改的字段,切面代碼在這些地方插入到你的應(yīng)用流程中,添加新的行為。切入點(diǎn)Pointcut定義了Advice應(yīng)該應(yīng)用在那些連接點(diǎn),通常通過指定類名和方法名,或者匹配類名和方法名式樣的正則表達(dá)式來指定切入點(diǎn)。

              2.2 AOP在Spring中的實現(xiàn)

              基于AOP,業(yè)界存在各種各樣的AOP實現(xiàn),比如,JBoss AOP、Spring AOP、AspectJ、Aspect Werkz等。各自實現(xiàn)的功能也不一樣。AOP實現(xiàn)的強(qiáng)弱在很大程度上取決于連接點(diǎn)模型。目前,Spring只支持方法級的連接點(diǎn)。這和一些其他AOP框架不一樣,如AspectJ和JBoss,它們還提供了屬性接入點(diǎn),這樣可以防止你創(chuàng)建特別細(xì)致的通知,如對更新對象屬性值進(jìn)行攔截。然而,由于Spring關(guān)注于提供一個實現(xiàn)J2EE服務(wù)的框架,所以方法攔截可以滿足大部分要求,而且Spring的觀點(diǎn)是屬性攔截破壞了封裝,讓Advice觸發(fā)在屬性值改變而不是方法調(diào)用上無疑是破壞了這個概念。

              Spring的AOP框架的關(guān)鍵點(diǎn)如下:

              (1)Spring實現(xiàn)了AOP聯(lián)盟接口。在Spring AOP中,存在如下幾種通知(Advice)類型

              Before通知:在目標(biāo)方法被調(diào)用前調(diào)用,涉及接口org.springframework.aop.MethodBeforeAdvice;

              After通知:在目標(biāo)方法被調(diào)用后調(diào)用,涉及接口為org.springframework.aop.AfterReturningAdvice;

              Throws通知:目標(biāo)方法拋出異常時調(diào)用,涉及接口org.springframework.aop.MethodBeforeAdvice;

              Around通知:攔截對目標(biāo)對象方法調(diào)用,涉及接口為org.aopalliance.intercept.MethodInterceptor。

              (2)用java編寫Spring通知,并在Spring的配置文件中,定義在什么地方應(yīng)用通知的切入點(diǎn)。

              (3)Spring的運(yùn)行時通知對象。代理Bean只有在第一次被應(yīng)用系統(tǒng)需要的時候才被創(chuàng)建。如果你使用的是ApplicationContext,代理對象在BeanFactory載入所有Bean的時候被創(chuàng)建。Spring有兩種代理創(chuàng)建方式。如果目標(biāo)對象實現(xiàn)了一個或多個接口暴露的方法,Spring將使用JDK的java.lang.reflect.Proxy類創(chuàng)建代理。這個類讓Spring動態(tài)產(chǎn)生一個新的類,它實現(xiàn)所需的接口,織入了通知,并且代理對目標(biāo)對象的所有請求。如果目標(biāo)對象沒有實現(xiàn)任何接口,Spring使用CGLIB庫生成目標(biāo)對象的子類。在創(chuàng)建這個子類的時候,Spring將通知織入,并且將對目標(biāo)對象的調(diào)用委托給這個子類。此時,需要將Spring發(fā)行包lib/cglib目錄下的JAR文件發(fā)布到應(yīng)用系統(tǒng)中。

              2.3 Spring AOP的優(yōu)勢

              借助于Spring AOP,Spring IoC能夠很方便的使用到非常健壯、靈活的企業(yè)級服務(wù),是因為Spring AOP能夠提供如下幾方面的優(yōu)勢:

              (1)允許開發(fā)者使用聲明式企業(yè)服務(wù),比如事務(wù)服務(wù)、安全性服務(wù);EJB開發(fā)者都知道,EJB組件能夠使用J2EE容器提供的聲明式服務(wù),但是這些服務(wù)要借助于EJB容器,而Spring AOP卻不需要EJB容器,借助于Spring的事務(wù)抽象框架就可以這些服務(wù)。

              (2)開發(fā)者可以開發(fā)滿足業(yè)務(wù)需求的自定義切面;

              (3)開發(fā)Spring AOP Advice很方便。因為這些AOP Advice僅是POJO類,借助于Spring提供的ProxyFactoryBean,能夠快速的搭建Spring AOP Advice。

              3、結(jié)語

              本文詳細(xì)闡述了Spring背后的IoC原理和AOP技術(shù),以實際成功項目為背景,抽取簡短片斷,展示了Spring架構(gòu)J2EE應(yīng)用系統(tǒng)的原理。Spring IoC借助于依賴注入機(jī)制,減輕了組件之間的依賴關(guān)系,同時也大大提高了組件的可移植性,組件得到了更多的重用機(jī)會。借助于Spring AOP,使得開發(fā)者能聲明式、基于元數(shù)據(jù)訪問企業(yè)級服務(wù),AOP合理補(bǔ)充了OOP技術(shù),Spring AOP合理地補(bǔ)充了Spring IoC容器。Spring IoC與Spring AOP組合,使得Spring成為成功的J2EE架構(gòu)框架,并能與標(biāo)準(zhǔn)的EJB等標(biāo)準(zhǔn)對抗,EJB不再是必需品。Spring已經(jīng)沖入了J2EE的核心,將引領(lǐng)整個J2EE開發(fā)、架構(gòu)的方向。

            原文鏈接:http://www.zhujiangroad.com/html/soft/s8445.html
            久久久久久精品成人免费图片| 久久久久高潮毛片免费全部播放| 国产欧美一区二区久久| 久久综合狠狠色综合伊人| 99久久亚洲综合精品网站| 无码乱码观看精品久久| 久久精品国产亚洲av麻豆图片| 国产精品久久国产精品99盘| 欧美久久一区二区三区| 亚洲∧v久久久无码精品| 精品久久久久久99人妻| 日韩人妻无码一区二区三区久久| 精品久久久久一区二区三区 | 99久久精品久久久久久清纯| 久久精品一本到99热免费| 久久久久久久99精品免费观看| 99久久国产热无码精品免费久久久久| 亚洲欧洲精品成人久久曰影片| 久久er热视频在这里精品| 久久久久亚洲精品日久生情 | 亚洲综合久久综合激情久久| 欧美成人免费观看久久| 国产成人精品久久| 国产亚洲精品自在久久| 久久久久国产精品人妻| 久久久久国产精品嫩草影院| www.久久精品| 久久精品国产亚洲AV无码偷窥| 2021国内久久精品| 亚洲精品国产综合久久一线| 久久狠狠一本精品综合网| 亚洲欧美日韩精品久久| 国产一级持黄大片99久久| 久久久亚洲欧洲日产国码二区 | 久久免费香蕉视频| 日本精品一区二区久久久| 久久99精品久久久久久齐齐 | 亚洲精品乱码久久久久66| 久久亚洲AV成人无码软件| 中文字幕久久精品无码| 久久综合给合久久狠狠狠97色|