從新來認識你的老朋友SPRING框架

Spring這個詞對於開發者想必不會陌生，可能你天天都在使用Spring，享受着Spring生態提供的服務，理所固然的用着SpringIOC和SpringAOP去實現老闆交給你的功能 ，唔 它就是這樣使用的（類聲明爲Bean組件，而後注入），沒錯 能完成老闆任務，沒毛病。若是向你提問什麼是Spring，Spring有什麼核心功能呢，你會想：這太簡單了，Spring就是框架嘛，Spring核心功能就是IOC和AOP，So Easy！！但是你真的瞭解Spring嗎？帶着這個疑問讓咱們一塊兒來從新瞭解一下Spring！

 

Spring的起源和根本使命

Spring是一個開源框架，最先由Rod Johnson建立，是爲了解決企業級應用開發的複雜性而建立的。不少框架都宣稱在某些方面針對Java開發作出了簡化，可是Spring的目標是致力於全方位簡化Java開發，這也是Spring的根本使命 "簡化Java開發"

 

 

Spring如何簡化Java開發

爲了下降Java開發的複雜性，Spring採起了如下4種關鍵策略，請務必牢記下面4中策略於心，這樣會幫助你更深的理解Spring。下面咱們來逐一解讀每一條策略，你就能明白Spring是如何簡化Java開發的。

• 基於POJO的輕量級和最小侵入性編程
• 經過依賴注入和麪向接口實現鬆耦合
• 基於切面和慣例進行聲明式編程
• 經過切面和模板減小樣版式代碼

1. 基於POJO的輕量級和最小侵入性編程

Spring竭力避免因自身的API而弄亂你的代碼。Spring不會強迫你實現Spring規範的接口或繼承Spring規範的類。相反，在一個基於Spring構建的應用中，應用中的類沒有任何痕跡代表你使用了Spring。最壞的狀況就是你在應用的類中發現了Spring的相關注解，但它依然是POJO，下面咱們來看一個在Spring中的一個POJO例子。

 

你能夠看到，這就是一個POJO（簡單的JAVA類），沒有任何地方代表它是Spring組件，Spring非侵入式編程模型意味着這個類在Spring應用和非Spring應用中均可以發揮一樣的做用。儘管看起來很簡單；但Spring經過IOC（Inversion of Control）管理這個POJO，而後經過DI（Dependency Inject）來注入他們，這個POJO就變的魔力十足；那麼DI是如何幫助應用對象彼此之間保持鬆耦合的呢？

在此我向你們推薦一個架構學習交流羣。交流學習羣號：874811168 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

2. 經過依賴注入和麪向接口實現鬆耦合

來咱們一塊兒來看一下一個簡單的POJO

 

在BeautifulGirl（可愛的小女孩）這個類中，在構造方法中建立一個EatAction（吃飯動做）。這樣就極大限制了BeautifulGirl（可愛的小女孩）的能力；若是如今小女孩須要去玩耍呢？或者須要去睡覺呢？真是太抱歉了，BeautifulGirl（可愛的小女孩）只會吃東西這個動做。這是什麼緣由呢？這就是BeautifulGirl（可愛的小女孩）和EatAction（吃飯動做）這兩個類牢牢耦合在了一塊兒！緊密耦合同時會形成代碼的難以測試，難以服用，難以理解，而且典型地表現出"打地鼠「式的Bug特性（修復一個Bug，將會出現一個或多個新Bug），因此咱們能夠知道耦合是必須的，但必須謹慎管理耦合，可是怎麼纔算是謹慎處理耦合關係呢？

 

上圖所示，DI（依賴注入）會將所依賴關係自動交給目標對象，而不是讓對象自己建立所依賴對象。對象的依賴關係將由系統中負責協調個對象依賴關係的第三方組件（相似Spring）在建立對象的時候設定。如今咱們明白了經過DI依賴注入能夠將對象之間依賴關係輕鬆解耦，那麼咱們來看一下簡單的實例吧。

 

從上面實例代碼中能夠看到BeautifulGirl自己並無建立任何的動做，而是經過構造方法傳入一個實現了Action（動做）接口的實現類便可，也就是說BeautifulGirl能夠完成任意實現了Action接口的動做（睡覺啦...玩耍啦...旅行啦....）。這裏的要點是BeautifulGirl沒有與任何特定的Action發生耦合。BeautifulGirl只須要的是一個實現Action接口就行，對象自己只是經過接口（而非具體實現或初始化過程）來代表依賴關係，那麼這種依賴就可以在BeautifulGirl不知情的狀況下替換不一樣的具體動做。好了咱們如今明白了DI進行依關係解耦的原理了，下面咱們看一下如何在Spring中應用DI。

 

 

這樣執行Main方法，從Context中獲取BeautifulGirl實例執行action方法。固然Spring提供了基於Java的配置，可做爲XML配置文件的代替方案

 

只不過Spring的上下文的實現應該使用AnnotationConfigApplicationContext進行加載配置

 

3. 基於切面和慣例進行聲明式編程

如今咱們已經明白DI可以將互相協做的軟件保持鬆耦合，而面向切面編程（aspect-oriented-programming，AOP）能夠將遍及應用各處的功能分離出來造成可從用的組件。咱們仍然使用上面的例子，BeautifulGirl爲所欲爲的執行各類動做真的沒問題嗎？若是可愛的小女孩執行的動做是去河邊玩耍，吃一些危險的東西呢？那麼咱們勢必須要一個家長（Parent類）進行監督小女孩的動做是不是安全的，下面咱們來看一下Parent類。

 

很是簡單！Parent（家長類）只有一個方法就是check，那麼如今就讓Parent對BeautifulGirl的執行動做進行檢查吧。

 

 

咱們很是聰明，使用了DI將Parent類注入到了BeautifulGirl類中，在BeautifulGirl執行action動做以前執行 parent.check()方法，這樣咱們要的效果就達到了。等等....好像有什麼不對的地方？

• 管理Parent家長的check動做真的是美麗的小女孩的職責嗎？
• 將Parent家長注入到美麗的小女孩類中不是將代碼複雜化了嗎？
• 咱們需不須要一個不須要家長注入的美麗的小女孩呢？
• 若是注入的Parent爲NULL咱們是否應該在美麗的小女孩中進行校驗呢？

 

真的是太糟糕了，注入一個Parent（家長）將會產生那麼多的問題，爲何呢？由於Parent類的業務於BeautifulGirl無關；BeautifulGirl將會承擔Parent類的職責。

 

在一個項目中，不少系統服務都會分佈到各個業務模塊中，這使得業務模塊的邏輯變得十分複雜，而使用AOP可以使這些服務模塊化，並以聲明式的方式將他們應用到他們所須要影響的組件中，使得這些組件將會具備更高的內聚性而且更加關注自身的業務邏輯，徹底不須要了解系統服務所帶來的複雜性。

下面咱們使用SpringAOP對上面代碼進行改造

 

 

咱們只須要在Spring配置文件中聲明Parent爲Spring Bean，而後將配置在SpringAOP中便可，咱們能夠發現BeautifulGirl類中沒有發現任何關於Parent的信息，這就是AOP的魅力所在——以聲明的方式將組件應用到他們所須要影響的組件中！

4. 經過切面和模板減小樣版式代碼

在經過JavaAPI進行編程，咱們常常會編寫不少重複的代碼例如JDBC訪問數據庫，JMS，JNDI等場景下會重複編寫大量的樣版式代碼，而Spring皆在經過模板封裝來消除模板式代碼，例如Spring針對JDBC訪問數據庫進行封裝的JdbcTemplate等，這裏就是Spring使用封裝的模板來減小JavaAPI樣版式代碼。