閑言碎語-逐步了解Spring

更新時間：2017年11月23日 09:51:15 作者：Wung

這篇文章主要介紹了閑言碎語-逐步了解Spring，涉及Spring的誕生，簡介，作用等相關(guān)內(nèi)容，具有一定參考價值，需要的朋友可以了解下。

WHY

在誕生之初，創(chuàng)建Spring的主要目的是用來替代更加重量級的企業(yè)級Java技術(shù)，尤其是EJB。相對于EJB來說，Spring提供了更加輕量級和簡單的編程模型。

WHAT

Spring是一個開源框架，最早由RodJohnson創(chuàng)建，Spring是為了解決企業(yè)級應(yīng)用開發(fā)的復(fù)雜性而創(chuàng)建的，使用Spring可以讓簡單的JavaBean實現(xiàn)之前只有EJB才能完成的事情。Spring不僅僅限于服務(wù)端的開發(fā)，任何Java應(yīng)用都能在簡單性、可測試性和松耦合等方面從Spring中獲益。

如今Spring在移動開發(fā)、社交API集成、NoSQL數(shù)據(jù)庫、云計算及大數(shù)據(jù)方面都在涉足。隨著時間的推移EJB也采用了依賴注入(DependencyInjection，DI)和面向切面編程(Aspect-OrientedProgramming，AOP)的理念。總之，Spring最根本的使命就是簡化Java開發(fā)

HOW

為了降低Java開發(fā)的復(fù)雜性，Spring采取了4鐘關(guān)鍵策略

基于POJO的輕量級和最小侵入性編程通過依賴注入和面向接口實現(xiàn)松耦合

基于切面和慣例進(jìn)行聲明式編程通過切面和模板減少樣式代碼

POJO潛能

很多框架通過強(qiáng)迫應(yīng)用繼承它們的類或?qū)崿F(xiàn)它們的接口從而導(dǎo)致應(yīng)用與框架綁定在一起，這就是侵入性編程，導(dǎo)致無法復(fù)用代碼塊。Spring竭力避免因自身的API而弄亂你的應(yīng)用代碼，在基于Spring構(gòu)建的應(yīng)用程序中，他的類通常沒有任何痕跡表明你使用了Spring

public class HelloWorldBean {
  public String sayHello(){
    return "Hello World";
  }
}

以上的實例代碼表示一個很簡單普通的Java類(POJO)，你看不出來他是一個Spring組件，Spring的非侵入式編程體現(xiàn)在這個類在Spring應(yīng)用和非Spring應(yīng)用中都可以發(fā)揮作用。僅僅這么一段代碼并沒有能實際體現(xiàn)Spring功能，還需要后面的知識。
依賴注入(將自身依賴的類注入的自身)

依賴注入這個此在Spring中并不是這么高大上，盡管現(xiàn)在已經(jīng)演變成一項復(fù)雜的編程技巧或者設(shè)計模式理念。在Spring中可以這么理解，注入依賴。一個具有實際意義的應(yīng)用都需要多個類進(jìn)行相互協(xié)作來完成特定的業(yè)務(wù)邏輯。傳統(tǒng)的做法是每個對象負(fù)責(zé)管理與自己有關(guān)的對象(這個有關(guān)的對象就是Spring中表述的所依賴的對象)的引用，不過這將會導(dǎo)致高度耦合和代碼難以測試

考慮如下代碼

/**這個拗口的類名是作者為了擬合一個模擬的場景特地取名
 * 這個類表示營救少女的騎士
 * Created by Wung on 2016/8/25.
 */
public class DamselRescuingKnight implements Knight{
	private RescueDamselQuest quest;
	/**
   * 在它的構(gòu)造函數(shù)中自行創(chuàng)建了RescueDamselQuest
   * 這使得DamselRescuingKnight和在它的構(gòu)造函數(shù)中自行創(chuàng)建了RescueDamselQuest耦合在了一起
   */
	public DamselRescuingKnight(){
		this.quest = new RescueDamselQuest();
	}
	public void embarkOnQuest(){
		quest.embark();
	}
}

耦合具有兩面性，一方面，緊密耦合的代碼難以測試難以復(fù)用難以理解，并且會出現(xiàn)"打地鼠"式的BUG。另一方面，一定程度的耦合又是必要的，不同的類必須以適當(dāng)?shù)姆绞竭M(jìn)行交互。

問題出現(xiàn)了，那么Spring是如何解決的呢

在Spring中，通過依賴注入(DI)，對象之間的依賴關(guān)系由系統(tǒng)中負(fù)責(zé)協(xié)調(diào)各對象的第三方組件在創(chuàng)建對象的時候進(jìn)行設(shè)定。也就是說對象只需要管理自己內(nèi)部的屬性而無需自行創(chuàng)建或者管理它們的依賴關(guān)系，依賴關(guān)系會被自動注入到需要它們的對象當(dāng)中去。

/**
 * 這個騎士可以執(zhí)行各種冒險任務(wù)而不在僅僅是之前那個營救少女的任務(wù)
 * Created by Wung on 2016/8/25.
 */
public class BraveKnight implements Knight{
	private Quest quest;
	/**
   * BraveKnight沒有自行創(chuàng)建冒險類型,而是在構(gòu)造的時候把冒險任務(wù)作為參數(shù)傳入
   * 這是依賴注入的方式之一:構(gòu)造器注入
   */
	public BraveKnight(Quest quest){
		this.quest = quest;
	}
	public void embarkOnQuest(){
		quest.embark();
	}
}

BraveKnight沒有與任何特定的Quest實現(xiàn)發(fā)生耦合，只要某個任務(wù)實現(xiàn)了Quest接口，那么具體是哪種類型的冒險就無所謂了，這就打到了DI的目的——松耦合

如果一個對象只通過接口來表明依賴關(guān)系，那么這種依賴關(guān)系就能夠在對象本身毫不知情的情況下用不同的具體實現(xiàn)來進(jìn)行替代。

那么現(xiàn)在來進(jìn)行實際意義的注入

對于上面那塊代碼我們來將一個具有具體實現(xiàn)的冒險任務(wù)注入到勇敢騎士中去

/**屠龍的冒險任務(wù)(這個作者好中二阿)
 * Created by Wung on 2016/8/25.
 */
public class SlayDragonQuest implements Quest{
	private PrintStream stream;
	public SlayDragonQuest(PrintStream stream){
		this.stream = stream;
	}
	public void embark() {
		stream.print("slay the dragon");
	}
}

那么現(xiàn)在問題來了，在SlayDragonQuest中如何注入它所依賴的PrintStream對象，在BraveKnight中如何注入它所依賴的Quest對象。前面提到的Spring會將這些依賴進(jìn)行集中管理，創(chuàng)建應(yīng)用組件之間協(xié)作的行為通常稱為裝配(wiring)也就是注入。Spring提供了多種裝配的方式在后面會更加詳細(xì)的介紹，此處簡單介紹基于XML的裝配和基于Java注解的裝配

<!--
    這就是一個裝配的過程，將SlayDragonQuest聲明為一個bean，取名為"quest"
    因為是構(gòu)造器注入所以使用constructor-arg屬性 value表示注入的值
    那么這個過程解決了之前的問題，將PrintStream對象注入到SlayDragonQuest對象中
  -->
  <bean class="impl.SlayDragonQuest" id="quest">
    <constructor-arg value="#{T(System).out}">
  </constructor-arg></bean>
 
  <!--
    這個過程同上，BraveKnight聲明為一個bean取名為"knight"(不一定使用到這個名字)
    然后BraveKnight的構(gòu)造器參數(shù)要求為Quest類型此時傳入了另外一個bean的引用
    就是上面這個名字"quest"的bean的引用，此時也完成了對BraveKnight的構(gòu)造器注入
   -->
  <bean class="impl.BraveKnight" id="knight">
    <constructor-arg ref="quest">
  </constructor-arg></bean>

Spring提供了基于Java的配置，可作為XML的替代方案

/**基于Java的配置文件實現(xiàn)對象的裝配
 * Created by Wung on 2016/8/26.
 */
@Configuration
public class KnightConfig {
   
  @Bean
  public Knight knight(){
    return new BraveKnight(quest());
  }
 
  @Bean
  public Quest quest(){
    return new SlayDragonQuest(System.out);
  }
}

效果是相同的，具體的解釋在下一章中詳細(xì)描述?，F(xiàn)在再來回顧一下，一直說Spring會自動管理對象之間的依賴關(guān)系，那么這種管理者是什么。答案是Application Context(應(yīng)用上下文)，它是Spring的一種容器，可以裝載bean的定義并將它們組裝起來。Spring應(yīng)用上下文全權(quán)負(fù)責(zé)對象的創(chuàng)建和組裝。實際上這個Context有好多中實現(xiàn)他們之間的區(qū)別僅僅是加載配置的方式不同，下面來看一種加載配置的方式

public class KnightMain {
 
  public static void main(String[] args){
    AnnotationConfigApplicationContext context = new
        AnnotationConfigApplicationContext(KnightConfig.class);
    //從配置文件中就可以獲取到bean的定義了
    Knight knight = context.getBean(Knight.class);
    knight.embarkOnQuest();
    context.close();
  }
 
}

應(yīng)用切面

DI能夠讓相互協(xié)作的軟件組件保持松耦合，而面向切面編程允許你把遍布應(yīng)用各處的功能分離出來形成可重用的組件，更詳細(xì)的說，它是促使軟件系統(tǒng)實現(xiàn)關(guān)注點奮力的一項技術(shù)。什么是關(guān)注點呢，諸如日志、事務(wù)管理、安全管理這樣的系統(tǒng)服務(wù)經(jīng)常需要融入到其他自身具有業(yè)務(wù)邏輯的組件中去，那么這些系統(tǒng)服務(wù)通常就被稱為橫切關(guān)注點，因為它們會在多個地方被重用，跨越系統(tǒng)的多個組件。簡單來說，就是你把需要重用的經(jīng)常會服務(wù)與各種其他組件的組件抽離出來，但是抽離出來如何使用呢，其實就是在用的時候?qū)⒎椒ú迦氲叫枰褂玫牡胤?。但是根?jù)這個"切面"的術(shù)語，應(yīng)該表述為將重用的組件抽離出來作為一個切面，在需要使用的時候?qū)⑶忻鏅M切進(jìn)組件。所以這樣就做到了核心應(yīng)用不需要知道這些切面的存在，切面也不會將業(yè)務(wù)邏輯融合在核心應(yīng)用中。

/**一個歌手類用來歌頌騎士也就是服務(wù)于騎士類
 * Created by Wung on 2016/8/26.
 */
public class Minstrel {
 
  private PrintStream stream;
 
  public Minstrel(PrintStream stream){
    this.stream = stream;
  }
  //在冒險之前執(zhí)行
  public void singBeforeQuest(){
    stream.print("Begin");
  }
  //在冒險之后執(zhí)行
  public void singAfterQuest(){
    stream.print("End");
  }
 
}

public class BraveKnight implements Knight{
	private Quest quest;
	private Minstrel minstrel;
	/**
   * BraveKnight沒有自行創(chuàng)建冒險類型,而是在構(gòu)造的時候把冒險任務(wù)作為參數(shù)傳入
   * 這是依賴注入的方式之一:構(gòu)造器注入
   */
	//  public BraveKnight(Quest quest){
	//    this.quest = quest;
	//  }
	public BraveKnight(Quest quest, Minstrel minstrel){
		this.quest = quest;
		this.minstrel = minstrel;
	}
	public void embarkOnQuest(){
		minstrel.singBeforeQuest();
		quest.embark();
		minstrel.singAfterQuest();
	}
}

這個時候這個勇敢的騎士開始執(zhí)行，但是他發(fā)現(xiàn)在他的職責(zé)中不僅僅是冒險了，現(xiàn)在竟然還要管理這個歌手要為他歌頌，然而這本身并不應(yīng)該屬于這個類應(yīng)該管理的。所以應(yīng)用切面的思想，我們需要將這個歌手的歌頌行為抽離出來成為一個切面，在騎士冒險之前這個切面將會橫切進(jìn)去執(zhí)行singBeforeQuest方法在冒險之后執(zhí)行singAfterQuest方法。那么這樣是不是就實現(xiàn)了騎士中不需要歌頌的代碼，歌手也不存在與騎士對象中，他將不僅僅贊頌騎士，也可以贊頌任何人只要別人使用這個切面切入即可

  <!-- 意思就是將上述id為minstrel的bean配置為切面實際上就是把歌手配置為切面 -->
  aspect ref="minstrel">
    <!-- 
      定義切入點，也就是在哪里會使用切面 
      expression="execution(* *.embarkOnQuest(..))
      是一種AspectJ的切點表達(dá)式語言后面會深入
      此處的意思是會在embarkOnQuest()方法處切入
      下面那個分別為前置通知和后置通知在切入點之前和之后執(zhí)行
    --> 
  </aop:after></aop:before></aop:pointcut>
</aop:</aop:config>

現(xiàn)在的情況是Minstrel仍然是獨立的一個POJO，Spring的上下文已經(jīng)將他變成了一個切面了。最重要的是此時騎士完全不知道這個切面的存在，這只是一個小小的栗子，實際上可以做很多重要的事情。

使用模板消除樣式代碼

有這樣一種情況，當(dāng)我們使用JDBC訪問數(shù)據(jù)庫查詢數(shù)據(jù)的時候，完整的流程需要建立連接、創(chuàng)建語句對象、處理結(jié)果集、查詢、關(guān)閉各種連接，此外還需要各種異常的捕獲，然后對于各種場景的查詢都需要如此費心費力的重復(fù)。JDBC還不僅僅是唯一這樣會有大量的樣式代碼的情況，Spring旨在通過模板封裝來消除樣式代碼，比如Spring的jdbcTemplate。

容納你的Bean

在基于Spring的應(yīng)用中，你的應(yīng)用對象生存于Spring容器，容器負(fù)責(zé)創(chuàng)建對象裝配對象并且管理他們的生命周期。那什么是Spring的容器呢，容器并不是只有一種，Spring自帶了多個容器實現(xiàn)。分為兩類:bean工廠，是最簡單的容器提供基本的DI支持。應(yīng)用上下文比較高級提供應(yīng)用框架級別的服務(wù)。大多數(shù)情況下應(yīng)用上下文更加受歡迎。

應(yīng)用上下文也分為多種，顯著的區(qū)別的是加載配置的方式不同

Spring的各種功能