轉載:http://www.javashuo.com/article/p-xrleykiz-o.html。html
Spring是一個開源框架,Spring是於2003 年興起的一個輕量級的Java 開發框架,由Rod Johnson 在其著做Expert One-On-One J2EE Development and Design中闡述的部分理念和原型衍生而來。它是爲了解決企業應用開發的複雜性而建立的。框架的主要優點之一就是其分層架構,分層架構容許使用者選擇使用哪個組件,同時爲 J2EE 應用程序開發提供集成的框架。Spring使用基本的JavaBean來完成之前只可能由EJB完成的事情。然而,Spring的用途不只限於服務器端的開發。從簡單性、可測試性和鬆耦合的角度而言,任何Java應用均可以從Spring中受益。Spring的核心是控制反轉(IoC)和麪向切面(AOP)。簡單來講,Spring是一個分層的JavaSE/EEfull-stack(一站式) 輕量級開源框架。web
特色:spring
簡單理解數據庫
一.概念:
1. spring是開源的輕量級框架編程
2 spring核心主要兩部分:設計模式
(1)aop:面向切面編程,擴展功能不修改源代碼實現,詳解【http://www.cnblogs.com/landeanfen/p/4782370.html】安全
(2)ioc:控制反轉服務器
好比有一個類,在類裏面有方法(不是靜態的方法),調用類裏面的方法,建立類的對象,使用對象調用方法,建立類對象的過程,須要new出來對象, 把對象的建立不是經過new方式實現,而是交給spring配置建立類對象。
我用通俗的話給你解釋把。首先你不用框架不是每次建立對象都要用關鍵字「new」呢?對吧。有了spring配置就不用new了,直接拿。舉個例子:假如你吃飯,每次你要吃飯時都要本身準備碗和筷子,每次都要本身準備,用了框架後,再 吃飯你只要吃就好了,就不用準備碗和筷子了由於spring已經給你準備好了。這樣是否是很方便。 spring主要就是不用你本身建立對象,都配置在配置文件中。若是你寫好一個項目,你再a類中建立了b類的方法,c類也建立了b類的方法,若是那天要改b類的類名,你就要在a和c中都改,若是有100個類都用了b類呢?那你不是要改死哦!! 若是用了spring,你只要修改配置文件一個位置就行了,是否是很方便維護呢。因此,小項目用不着spring框架。手打好累。。。
ioc:控制反轉
ioc的思想最核心的地方在於,資源不禁使用資源的雙方管理,而由不使用資源的第三方管理,這能夠帶來不少好處。第一,資源集中管理,實現資源的可配置和易管理。第二,下降了使用資源雙方的依賴程度,也就是咱們說的耦合度。架構
也就是說,甲方要達成某種目的不須要直接依賴乙方,它只須要達到的目的告訴第三方機構就能夠了,好比甲方須要一雙襪子,而乙方它賣一雙襪子,它要把襪子賣出去,並不須要本身去直接找到一個賣家來完成襪子的賣出。它也只須要找第三方,告訴別人我要賣一雙襪子。這下好了,甲乙雙方進行交易活動,都不須要本身直接去找賣家,至關於程序內部開放接口,賣家由第三方做爲參數傳入。甲乙互相不依賴,並且只有在進行交易活動的時候,甲才和乙產生聯繫。反之亦然。這樣作什麼好處麼呢,甲乙能夠在對方不真實存在的狀況下獨立存在,並且保證不交易時候無聯繫,想交易的時候能夠很容易的產生聯繫。甲乙交易活動不須要雙方見面,避免了雙方的互不信任形成交易失敗的問題。由於交易由第三方來負責聯繫,並且甲乙都認爲第三方可靠。那麼交易就能很可靠很靈活的產生和進行了。app
這就是ioc的核心思想。生活中這種例子比比皆是,支付寶在整個淘寶體系裏就是龐大的ioc容器,交易雙方以外的第三方,提供可靠性可依賴可靈活變動交易方的資源管理中心。另外人事代理也是,僱傭機構和我的以外的第三方。
控制反轉( Inversion of Control ), 我以爲有必要先了解軟件設計的一個重要思想:依賴倒置原則(Dependency Inversion Principle )。
什麼是依賴倒置原則?假設咱們設計一輛汽車:先設計輪子,而後根據輪子大小設計底盤,接着根據底盤設計車身,最後根據車身設計好整個汽車。這裏就出現了一個「依賴」關係:汽車依賴車身,車身依賴底盤,底盤依賴輪子。
這樣的設計看起來沒問題,可是可維護性卻很低。假設設計完工以後,上司卻忽然說根據市場需求的變更,要咱們把車子的輪子設計都改大一碼。這下咱們就蛋疼了:由於咱們是根據輪子的尺寸設計的底盤,輪子的尺寸一改,底盤的設計就得修改;一樣由於咱們是根據底盤設計的車身,那麼車身也得改,同理汽車設計也得改——整個設計幾乎都得改!
咱們如今換一種思路。咱們先設計汽車的大概樣子,而後根據汽車的樣子來設計車身,根據車身來設計底盤,最後根據底盤來設計輪子。這時候,依賴關係就倒置過來了:輪子依賴底盤, 底盤依賴車身, 車身依賴汽車。
這時候,上司再說要改動輪子的設計,咱們就只須要改動輪子的設計,而不須要動底盤,車身,汽車的設計了。
這就是依賴倒置原則——把本來的高層建築依賴底層建築「倒置」過來,變成底層建築依賴高層建築。高層建築決定須要什麼,底層去實現這樣的需求,可是高層並不用管底層是怎麼實現的。這樣就不會出現前面的「牽一髮動全身」的狀況。
控制反轉(Inversion of Control) 就是依賴倒置原則的一種代碼設計的思路。具體採用的方法就是所謂的依賴注入(Dependency Injection)。其實這些概念初次接觸都會感到雲裏霧裏的。說穿了,這幾種概念的關係大概以下:
爲了理解這幾個概念,咱們仍是用上面汽車的例子。只不過此次換成代碼。咱們先定義四個Class,車,車身,底盤,輪胎。而後初始化這輛車,最後跑這輛車。代碼結構以下:
這樣,就至關於上面第一個例子,上層建築依賴下層建築——每個類的構造函數都直接調用了底層代碼的構造函數。假設咱們須要改動一下輪胎(Tire)類,把它的尺寸變成動態的,而不是一直都是30。咱們須要這樣改:
因爲咱們修改了輪胎的定義,爲了讓整個程序正常運行,咱們須要作如下改動:
由此咱們能夠看到,僅僅是爲了修改輪胎的構造函數,這種設計卻須要修改整個上層全部類的構造函數!在軟件工程中,這樣的設計幾乎是不可維護的——在實際工程項目中,有的類可能會是幾千個類的底層,若是每次修改這個類,咱們都要修改全部以它做爲依賴的類,那軟件的維護成本就過高了。
因此咱們須要進行控制反轉(IoC),及上層控制下層,而不是下層控制着上層。咱們用依賴注入(Dependency Injection)這種方式來實現控制反轉。所謂依賴注入,就是把底層類做爲參數傳入上層類,實現上層類對下層類的「控制」。這裏咱們用構造方法傳遞的依賴注入方式從新寫車類的定義:
這裏咱們再把輪胎尺寸變成動態的,一樣爲了讓整個系統順利運行,咱們須要作以下修改:
看到沒?這裏我只須要修改輪胎類就好了,不用修改其餘任何上層類。這顯然是更容易維護的代碼。不只如此,在實際的工程中,這種設計模式還有利於不一樣組的協同合做和單元測試:好比開發這四個類的分別是四個不一樣的組,那麼只要定義好了接口,四個不一樣的組能夠同時進行開發而不相互受限制;而對於單元測試,若是咱們要寫Car類的單元測試,就只須要Mock一下Framework類傳入Car就好了,而不用把Framework, Bottom, Tire所有new一遍再來構造Car。
這裏咱們是採用的構造函數傳入的方式進行的依賴注入。其實還有另外兩種方法:Setter傳遞和接口傳遞。這裏就很少講了,核心思路都是同樣的,都是爲了實現控制反轉。
看到這裏你應該能理解什麼控制反轉和依賴注入了。那什麼是控制反轉容器(IoC Container)呢?其實上面的例子中,對車類進行初始化的那段代碼發生的地方,就是控制反轉容器。
顯然你也應該觀察到了,由於採用了依賴注入,在初始化的過程當中就不可避免的會寫大量的new。這裏IoC容器就解決了這個問題。這個容器能夠自動對你的代碼進行初始化,你只須要維護一個Configuration(能夠是xml能夠是一段代碼),而不用每次初始化一輛車都要親手去寫那一大段初始化的代碼。這是引入IoC Container的第一個好處。
IoC Container的第二個好處是:咱們在建立實例的時候不須要了解其中的細節。在上面的例子中,咱們本身手動建立一個車instance時候,是從底層往上層new的:
這個過程當中,咱們須要瞭解整個Car/Framework/Bottom/Tire類構造函數是怎麼定義的,才能一步一步new/注入。
而IoC Container在進行這個工做的時候是反過來的,它先從最上層開始往下找依賴關係,到達最底層以後再往上一步一步new(有點像深度優先遍歷):
這裏IoC Container能夠直接隱藏具體的建立實例的細節,在咱們來看它就像一個工廠:
咱們就像是工廠的客戶。咱們只須要向工廠請求一個Car實例,而後它就給咱們按照Config建立了一個Car實例。咱們徹底不用管這個Car實例是怎麼一步一步被建立出來。
實際項目中,有的Service Class多是十年前寫的,有幾百個類做爲它的底層。假設咱們新寫的一個API須要實例化這個Service,咱們總不可能回頭去搞清楚這幾百個類的構造函數吧?IoC Container的這個特性就很完美的解決了這類問題——由於這個架構要求你在寫class的時候須要寫相應的Config文件,因此你要初始化好久之前的Service類的時候,前人都已經寫好了Config文件,你直接在須要用的地方注入這個Service就能夠了。這大大增長了項目的可維護性且下降了開發難度。