什麼是spring框架？spring特色與好處,使用spring框架的好處是什麼？

時間 2020-06-03

原文原文鏈接

轉載：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提供的IoC容器，咱們能夠將對象之間的依賴關係交由Spring進行控制，避免硬編碼所形成的過分程序耦合。有了Spring，用戶沒必要再爲單實例模式類、屬性文件解析等這些很底層的需求編寫代碼，能夠更專一於上層的應用。

2.AOP編程的支持

　　經過Spring提供的AOP功能，方便進行面向切面的編程，許多不容易用傳統OOP實現的功能能夠經過AOP輕鬆應付。

3.聲明事物的支持

　　在Spring中，咱們能夠從單調煩悶的事務管理代碼中解脫出來，經過聲明式方式靈活地進行事務的管理，提升開發效率和質量。

4.方便程序的測試

　　能夠用非容器依賴的編程方式進行幾乎全部的測試工做，在Spring裏，測試再也不是昂貴的操做，而是隨手可作的事情。例如：Spring對Junit4支持，能夠經過註解方便的測試Spring程序。

5.方便集成各類優秀框架

　　Spring不排斥各類優秀的開源框架，相反，Spring能夠下降各類框架的使用難度，Spring提供了對各類優秀框架（如Struts,Hibernate、Hessian、Quartz）等的直接支持。

6.下降Java EE API的使用難度

　　Spring對不少難用的Java EE API（如JDBC，JavaMail，遠程調用等）提供了一個薄薄的封裝層，經過Spring的簡易封裝，這些Java EE API的使用難度大爲下降。

7.Java 源碼是經典學習範例

　　　　Spring的源碼設計精妙、結構清晰、匠心獨用，到處體現着大師對Java設計模式靈活運用以及對Java技術的高深造詣。Spring框架源碼無疑是Java技術的最佳實踐範例。若是想在短期內迅速提升本身的Java技術水平和應用開發水平，學習和研究Spring源碼將會使你收到意想不到的效果。

好處：

在咱們進入細節之前，讓咱們看一下Spring能夠給一個工程帶來的一些好處：

　　Spring能有效地組織你的中間層對象，不管你是否選擇使用了EJB。若是你僅僅使用了Struts或其餘的包含了J2EE特有APIs的framework，你會發現Spring關注了遺留下的問題。Spring能消除在許多工程上對Singleton的過多使用。根據個人經驗，這是一個主要的問題，它減小了系統的可測試性和麪向對象特性。

　　Spring能消除使用各類各樣格式的屬性定製文件的須要，在整個應用和工程中，可經過一種一致的方法來進行配置。曾經感到迷惑，一個特定類要查找迷幻般的屬性關鍵字或系統屬性，爲此不得不讀Javadoc乃至源編碼嗎？有了Spring，你可很簡單地看到類的JavaBean屬性。倒置控制的使用（在下面討論）幫助完成這種簡化。

　　Spring能經過接口而不是類促進好的編程習慣，減小編程代價到幾乎爲零。

　　Spring被設計爲讓使用它建立的應用盡量少的依賴於他的APIs。在Spring應用中的大多數業務對象沒有依賴於Spring。

使用Spring構建的應用程序易於單元測試。

　　Spring能使EJB的使用成爲一個實現選擇，而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務接口，卻不會影響調用代碼。

　　Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適於許多web應用。例如，Spring能使用AOP提供聲明性事務而不經過使用EJB容器，若是你僅僅須要與單個的數據庫打交道，甚至不須要JTA實現。

　　Spring爲數據存取提供了一致的框架，不管是使用JDBC或O/R mapping產品（如Hibernate）。

　　Spring確實使你能經過最簡單可行的解決辦法解決你的問題。這些特性是有很大價值的。

總結起來，Spring有以下優勢：

1.低侵入式設計，代碼污染極低

2.獨立於各類應用服務器，基於Spring框架的應用，能夠真正實現Write Once,Run Anywhere的承諾

3.Spring的DI機制下降了業務對象替換的複雜性，提升了組件之間的解耦

4.Spring的AOP支持容許將一些通用任務如安全、事務、日誌等進行集中式管理，從而提供了更好的複用

5.Spring的ORM和DAO提供了與第三方持久層框架的良好整合，並簡化了底層的數據庫訪問

6.Spring並不強制應用徹底依賴於Spring，開發者可自由選用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就能夠了。這大大增長了項目的可維護性且下降了開發難度。

轉載： http://www.javashuo.com/article/p-xrleykiz-o.html。