Spring的核心機制

管理Bean

程序主要是經過Spring容器來訪問容器中的Bean，ApplicationContext是Spring容器最經常使用的接口，該接口有以下兩個實現類

• ClassPathXmlApplicationContext: 從類加載路徑下搜索配置文件，並根據配置文件來建立Spring容器

• FileSystemXmlApplicationContext: 從文件系統的相對路徑或絕對路徑下去搜索配置文件，並根據配置文件來建立Spring容器

public class BeanTest{
    public static void main(String args[]) throws Exception{
        ApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
        Person p = ctx.getBean("person", Person.class);
        p.say();
    }
}

Eclipse使用Spring

在Eclipse等IDE工具中，用戶能夠自建User Library，而後把Spring的Jar包都放入其中，固然也能夠將Jar包直接放在項目的/WEB-INF/lib目錄下，可是若是使用User Library，在項目發佈時，須要將用戶庫所引用的Jar文件隨應用一塊兒發佈，就是將User Library所使用的Jar複製到/WEB-INF/lib目錄下，這是由於對於一個Web應用，Eclipse部署Web應用時不會將用戶庫的Jar文件複製到/WEB-INF/lib下，須要手動複製。

依賴注入

Spring框架的核心功能有兩個

• Spring容器做爲超級大工廠，負責建立、管理全部的Java對象，這些Java對象被稱爲Bean。

• Spring容器管理容器中Bean之間的依賴關係，Spring使用一種被稱爲「依賴注入」的方式來管理Bean之間的依賴關係。

使用依賴注入，不只能夠爲Bean注入普通的屬性值，還能夠注入其餘Bean的引用。依賴注入是一種優秀的解耦方式，其可讓Bean以配置文件組織在一塊兒，而不是以硬編碼的方式耦合在一塊兒。

理解依賴注入

Rod Johnson是第一個高度重視以配置文件來管理Java實例的協做關係的人，他給這種方式起了一個名字：控制反轉（Inverse of Control，IoC）。後來Martine Fowler爲這種方式起了另外一個名稱：依賴注入（Dependency Injection），所以無論是依賴注入，仍是控制反轉，其含義徹底相同。當某個Java對象（調用者）須要調用另外一個Java對象（被依賴對象）的方 法時，在傳統模式下一般有兩種作法

1. 原始作法：調用者主動建立被依賴對象，而後再調用被依賴對象的方法。

2. 簡單工廠模式：調用者先找到被依賴對象的工廠，而後主動經過工廠去獲取被依賴對象，最後再調用被依賴對象的方法。

注意上面的主動二字，這必然會致使調用者與被依賴對象實現類的硬編碼耦合，很是不利於項目升級的維護。使用Spring框架以後，調用者無需主動獲取被依賴對象，調用者只要被動接受Spring容器爲調用者的成員變量賦值便可，因而可知，使用Spring後，調用者獲取被依賴對象的方式由原來的主動獲取，變成了被動接受——因此Rod Johnson稱之爲控制反轉。

另外從Spring容器的角度來看，Spring容器負責將被依賴對象賦值給調用者的成員變量——至關於爲調用者注入它依賴的實例，所以Martine Fowler稱之爲依賴注入。

設值注入

設值注入是指IoC容器經過成員變量的setter方法來注入被依賴對象。這種注入方式簡單、直觀，於是在Spring的依賴注入裏大量使用。

構造注入

利用構造器來設置依賴關係的方式，被稱爲構造注入。通俗來講，就是驅動Spring在底層以反射方式執行帶指定參數的構造器，當執行帶參數的構造器時，就可利用構造器參數對成員變量執行初始化——這就是構造注入的本質。

兩種注入方式的對比

設值注入有以下優勢

• 與傳統的JavaBean的寫法更類似，程序開發人員更容易理解、接受。經過setter方法設定依賴關係顯得更加直觀、天然。

• 對於複雜的依賴關係，若是採用構造注入，會致使構造器過於臃腫，難以閱讀。Spring在建立Bean實例時，須要同時實例化其依賴的所有實例，於是致使性能降低。而使用設值注入，則能避免這些問題。

• 尤爲在某些成員變量可選的狀況下，多參數的構造器更加笨重。

構造注入優點以下

• 構造注入能夠在構造器中決定依賴關係的注入順序，優先依賴的優先注入。

• 對於依賴關係無需變化的Bean，構造注入更有用處。由於沒有setter方法，全部的依賴關係所有在構造器內設定，無須擔憂後續的代碼對依賴關係產生破壞。

• 依賴關係只能在構造器中設定，則只有組件的建立者才能改變組件的依賴關係，對組件的調用者而言，組件內部的依賴關係徹底透明，更符合高內聚的原則。

Notes
建議採用設值注入爲主，構造注入爲輔的注入策略。對於依賴關係無須變化的注入，儘可能採用構造注入；而其餘依賴關係的注入，則考慮採用設值注入。

Spring容器中的Bean

對於開發者來講，開發者使用Spring框架主要是作兩件事：①開發Bean；②配置Bean。對於Spring框架來講，它要作的就是根據配置文件來建立Bean實例，並調用Bean實例的方法完成「依賴注入」——這就是所謂IoC的本質。

容器中Bean的做用域

當經過Spring容器建立一個Bean實例時，不只能夠完成Bean實例的實例化，還能夠爲Bean指定特定的做用域。Spring支持以下五種做用域：

1. singleton：單例模式，在整個Spring IoC容器中，singleton做用域的Bean將只生成一個實例。

2. prototype：每次經過容器的getBean()方法獲取prototype做用域的Bean時，都將產生一個新的Bean實例。

3. request：對於一次HTTP請求，request做用域的Bean將只生成一個實例，這意味着，在同一次HTTP請求內，程序每次請求該Bean，獲得的老是同一個實例。只有在Web應用中使用Spring時，該做用域才真正有效。

4. 對於一次HTTP會話，session做用域的Bean將只生成一個實例，這意味着，在同一次HTTP會話內，程序每次請求該Bean，獲得的老是同一個實例。只有在Web應用中使用Spring時，該做用域才真正有效。

5. global session：每一個全局的HTTP Session對應一個Bean實例。在典型的狀況下，僅在使用portlet context的時候有效，一樣只在Web應用中有效。

若是不指定Bean的做用域，Spring默認使用singleton做用域。prototype做用域的Bean的建立、銷燬代價比較大。而 singleton做用域的Bean實例一旦建立成果，就能夠重複使用。所以，應該儘可能避免將Bean設置成prototype做用域。

使用自動裝配注入合做者Bean

Spring能自動裝配Bean與Bean之間的依賴關係，即無須使用ref顯式指定依賴Bean，而是由Spring容器檢查XML配置文件內容，根據某種規則，爲調用者Bean注入被依賴的Bean。
Spring自動裝配可經過<beans/>元素的default-autowire屬性指定，該屬性對配置文件中全部的Bean起做用；也可經過對<bean/>元素的autowire屬性指定，該屬性只對該Bean起做用。

autowire和default-autowire能夠接受以下值

• no: 不使用自動裝配。Bean依賴必須經過ref元素定義。這是默認配置，在較大的部署環境中不鼓勵改變這個配置，顯式配置合做者可以獲得更清晰的依賴關係

• byName: 根據setter方法名進行自動裝配。Spring容器查找容器中所有Bean，找出其id與setter方法名去掉set前綴，並小寫首字母后同名的Bean來完成注入。若是沒有找到匹配的Bean實例，則Spring不會進行任何注入

• byType: 根據setter方法的形參類型來自動裝配。Spring容器查找容器中的所有Bean，若是正好有一個Bean類型與setter方法的形參類型匹配， 就自動注入這個Bean；若是找到多個這樣的Bean，就拋出一個異常；若是沒有找到這樣的Bean，則什麼都不會發生，setter方法不會被調用。

• constructor: 與byType相似，區別是用於自動匹配構造器的參數。若是容器不能剛好找到一個與構造器參數類型匹配的Bean，則會拋出一個異常。

• autodetect: Spring容器根據Bean內部結構，自行決定使用constructor或byType策略。若是找到一個默認的構造函數，那麼就會應用byType策略。

當一個Bean既使用自動裝配依賴，又使用ref顯式指定依賴時，則顯式指定的依賴覆蓋自動裝配依賴；對於大型的應用，不鼓勵使用自動裝配。雖然使用自動裝配可減小配置文件的工做量，但大大將死了依賴關係的清晰性和透明性。依賴關係的裝配依賴於源文件的屬性名和屬性類型，致使 Bean與Bean之間的耦合下降到代碼層次，不利於高層次解耦。

<!--經過設置能夠將Bean排除在自動裝配以外-->
<bean id="" autowire-candidate="false"/>

<!--除此以外，還能夠在beans元素中指定，支持模式字符串，以下全部以abc結尾的Bean都被排除在自動裝配以外-->
<beans default-autowire-candidates="*abc"/>

建立Bean的3種方式

使用構造器建立Bean實例

使用構造器來建立Bean實例是最多見的狀況，若是不採用構造注入，Spring底層會調用Bean類的無參數構造器來建立實例，所以要求該Bean類提供無參數的構造器。

採用默認的構造器建立Bean實例，Spring對Bean實例的全部屬性執行默認初始化，即全部的基本類型的值初始化爲0或false；全部的引用類型的值初始化爲null。

使用靜態工廠方法建立Bean

使用靜態工廠方法建立Bean實例時，class屬性也必須指定，但此時class屬性並非指定Bean實例的實現類，而是靜態工廠類，Spring經過該屬性知道由哪一個工廠類來建立Bean實例。

除此以外，還須要使用factory-method屬性來指定靜態工廠方法，Spring將調用靜態工廠方法返回一個Bean實例，一旦得到了指定Bean實例，Spring後面的處理步驟與採用普通方法建立Bean實例徹底同樣。若是靜態工廠方法須要參數，則使用<constructor-arg.../>元素指定靜態工廠方法的參數。

調用實例工廠方法建立Bean

實例工廠方法與靜態工廠方法只有一個不一樣：調用靜態工廠方法只需使用工廠類便可，而調用實例工廠方法則須要工廠實例。使用實例工廠方法時，配置Bean實例的<bean.../>元素無須class屬性，配置實例工廠方法使用factory-bean指定工廠實例。
採用實例工廠方法建立Bean的<bean.../>元素時須要指定以下兩個屬性

• factory-bean: 該屬性的值爲工廠Bean的id

• factory-method: 該屬性指定實例工廠的工廠方法

若調用實例工廠方法時須要傳入參數，則使用<constructor-arg.../>元素肯定參數值。

協調做用域不一樣步的Bean

當singleton做用域的Bean依賴於prototype做用域的Bean時，會產生不一樣步的現象，緣由是由於當Spring容器初始化時，容器會預初始化容器中全部的singleton Bean，因爲singleton Bean依賴於prototype Bean，所以Spring在初始化singleton Bean以前，會先建立prototypeBean——而後才建立singleton Bean，接下里將prototype Bean注入singleton Bean。
解決不一樣步的方法有兩種

• 放棄依賴注入: singleton做用域的Bean每次須要prototype做用域的Bean時，主動向容器請求新的Bean實例，便可保證每次注入的prototype Bean實例都是最新的實例

• 利用方法注入: 方法注入一般使用lookup方法注入，使用lookup方法注入可讓Spring容器重寫容器中Bean的抽象或具體方法，返回查找容器中其餘Bean的結果，被查找的Bean一般是一個non-singleton Bean。Spring經過使用JDK動態代理或cglib庫修改客戶端的二進制碼，從而實現上述要求

建議採用第二種方法，使用方法注入。爲了使用lookup方法注入，大體須要以下兩步

1. 將調用者Bean的實現類定義爲抽象類，並定義一個抽象方法來獲取被依賴的Bean

2. 在<bean.../>元素中添加<lookup-method.../>子元素讓Spring爲調用者Bean的實現類實現指定的抽象方法

Notes

Spring會採用運行時動態加強的方式來實現<lookup-method.../>元 素所指定的抽象方法，若是目標抽象類實現過接口，Spring會採用JDK動態代理來實現該抽象類，併爲之實現抽象方法；若是目標抽象類沒有實現過接 口，Spring會採用cglib實現該抽象類，併爲之實現抽象方法。Spring4.0的spring-core-xxx.jar包中已經集成了 cglib類庫。

兩種後處理器

Spring提供了兩種經常使用的後處理器

• Bean後處理器: 這種後處理器會對容器中Bean進行後處理，對Bean進行額外增強

• 容器後處理器: 這種後處理器會對IoC容器進行後處理，用於加強容器功能

Bean後處理器

Bean後處理器是一種特殊的Bean，這種特殊的Bean並不對外提供服務，它甚至能夠無須id屬性，它主要負責對容器中的其餘Bean執行後處 理，例如爲容器中的目標Bean生成代理等，這種Bean稱爲Bean後處理器。Bean後處理器會在Bean實例建立成功以後，對Bean實例進行進一 步的加強處理。Bean後處理器必須實現BeanPostProcessor接口，同時必須實現該接口的兩個方法。

1. Object postProcessBeforeInitialization(Object bean, String name) throws BeansException: 該方法的第一個參數是系統即將進行後處理的Bean實例，第二個參數是該Bean的配置id

2. Object postProcessAfterinitialization(Object bean, String name) throws BeansException: 該方法的第一個參數是系統即將進行後處理的Bean實例，第二個參數是該Bean的配置id

容器中一旦註冊了Bean後處理器，Bean後處理器就會自動啓動，在容器中每一個Bean建立時自動工做，Bean後處理器兩個方法的回調時機以下圖

bean-post-process

注意一點，若是使用BeanFactory做爲Spring容器，則必須手動註冊Bean後處理器，程序必須獲取Bean後處理器實例，而後手動註冊。

BeanPostProcessor bp = (BeanPostProcessor)beanFactory.getBean("bp");
beanFactory.addBeanPostProcessor(bp);
Person p = (Person)beanFactory.getBean("person");

容器後處理器

Bean後處理器負責處理容器中的全部Bean實例，而容器後處理器則負責處理容器自己。容器後處理器必須實現BeanFactoryPostProcessor接口，並實現該接口的一個方法postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)實現該方法的方法體就是對Spring容器進行的處理，這種處理能夠對Spring容器進行自定義擴展，固然也能夠對Spring容器不進行任何處理。

相似於BeanPostProcessor，ApplicationContext可自動檢測到容器中的容器後處理器，而且自動註冊容器後處理器。但若使用BeanFactory做爲Spring容器，則必須手動調用該容器後處理器來處理BeanFactory容器。

Spring的「零配置」支持

搜索Bean類

Spring提供以下幾個Annotation來標註Spring Bean

• @Component: 標註一個普通的Spring Bean類

• @Controller : 標註一個控制器組件類

• @Service : 標註一個業務邏輯組件類

• @Repository: 標註一個DAO組件類

在Spring配置文件中作以下配置，指定自動掃描的包

<context:component-scan base-package="edu.shu.spring.domain"/>

使用@Resource配置依賴

@Resource位於javax.annotation包下，是來自JavaEE規範的一個Annotation，Spring直接借鑑了該Annotation，經過使用該Annotation爲目標Bean指定協做者Bean。使用@Resource與<property.../>元素的ref屬性有相同的效果。
@Resource不只能夠修飾setter方法，也能夠直接修飾實例變量，若是使用@Resource修飾實例變量將會更加簡單，此時Spring將會直接使用JavaEE規範的Field注入，此時連setter方法均可以不要。

使用@PostConstruct和@PreDestroy定製生命週期行爲

@PostConstruct和@PreDestroy一樣位於 javax.annotation包下，也是來自JavaEE規範的兩個Annotation，Spring直接借鑑了它們，用於定製Spring容器中 Bean的生命週期行爲。它們都用於修飾方法，無須任何屬性。其中前者修飾的方法時Bean的初始化方法；然後者修飾的方法時Bean銷燬以前的方法。

Spring4.0加強的自動裝配和精確裝配

Spring提供了@Autowired註解來指定自動裝配，@Autowired能夠修飾setter方法、普通方法、實例變量和構造器等。當使用@Autowired標註setter方法時，默認採用byType自動裝配策略。在這種策略下，符合自動裝配類型的候選Bean實例經常有多個，這個時候就可能引發異常，爲了實現精確的自動裝配，Spring提供了@Qualifier註解，經過使用@Qualifier，容許根據Bean的id來執行自動裝配。

Spring的AOP

爲何須要AOP

AOP（Aspect Orient Programming）也就是面向切面編程，做爲面向對象編程的一種補充，已經成爲一種比較成熟的編程方式。其實AOP問世的時間並不太長，AOP和OOP互爲補充，面向切面編程將程序運行過程分解成各個切面。

AOP專門用於處理系統中分佈於各個模塊（不一樣方法）中的交叉關注點的問題，在JavaEE應用中，經常經過AOP來處理一些具備橫切性質的系統級服務，如事務管理、安全檢查、緩存、對象池管理等，AOP已經成爲一種很是經常使用的解決方案。

使用AspectJ實現AOP

AspectJ是一個基於Java語言的AOP框架，提供了強大的AOP功能，其餘不少AOP框架都借鑑或採納其中的一些思想。其主要包括兩個部 分：一個部分定義瞭如何表達、定義AOP編程中的語法規範，經過這套語法規範，能夠方便地用AOP來解決Java語言中存在的交叉關注點的問題；另外一個部 分是工具部分，包括編譯、調試工具等。

AOP實現可分爲兩類

1. 靜態AOP實現: AOP框架在編譯階段對程序進行修改，即實現對目標類的加強，生成靜態的AOP代理類，以AspectJ爲表明

2. 動態AOP實現: AOP框架在運行階段動態生成AOP代理，以實現對目標對象的加強，以Spring AOP爲表明

通常來講，靜態AOP實現具備較好的性能，但須要使用特殊的編譯器。動態AOP實現是純Java實現，所以無須特殊的編譯器，可是一般性能略差。

AOP的基本概念

關於面向切面編程的一些術語

• 切面（Aspect）: 切面用於組織多個Advice，Advice放在切面中定義

• 鏈接點（Joinpoint）: 程序執行過程當中明確的點，如方法的調用，或者異常的拋出。在Spring AOP中，鏈接點老是方法的調用

• 加強處理（Advice）: AOP框架在特定的切入點執行的加強處理。處理有「around」、「before」和「after」等類型

• 切入點（Pointcut）: 能夠插入加強處理的鏈接點。簡而言之，當某個鏈接點知足指定要求時，該鏈接點將被添加加強處理，該鏈接點也就變成了切入點

Spring的AOP支持

Spring中的AOP代理由Spring的IoC容器負責生成、管理，其依賴關係也由IoC容器負責管理。
爲了在應用中使用@AspectJ支持，Spring須要添加三個庫

• aspectjweaver.jar

• aspectjrt.jar

• aopalliance.jar

並在Spring配置文件中作以下配置

<!--啓動@AspectJ支持-->
<aop:aspectj-autoproxy/>

<!--指定自動搜索Bean組件、自動搜索切面類-->
<context:component-scan base-package="edu.shu.sprint.service">
    <context:include-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/>
</context:component-scan>