前言
如今做Java尤其是web幾乎是避免不了和Spring打交道了,但是Spring是這樣的大而全,新鮮名詞不斷產生,學起來給人一種凌亂的感覺,在這裡總結一下,理順頭緒。
Spring 概述
Spring 是一個開源框架,是為了解決企業應用程式開發複雜性而建立的(替代更加重量級的企業級Java技術, 尤其是EJB),它完成了大量開發中的通用步驟,留給開發者的僅僅是與特定應用相關的部分,從而大大提高了企業應用的開發效率。
Spring 框架是一個分層架構,由 7 個定義良好的模組組成。Spring 模組構建在核心容器之上,核心容器定義了建立、配置和管理 bean 的方式如下圖:
組成 Spring 框架的每個模組都可以單獨存在,或者與其他一個或多個模組聯合實現。每個模組的功能如下:
1.Spring 核心容器:
核心容器提供 Spring 框架的基本功能,管理著Spring應用中bean的建立、配置和管理。核心容器的主要元件是 BeanFactory,它是工廠模式的實現。BeanFactory 使用DI將應用程式的配置和依賴性規範與實際的應用程式程式碼分開。
2.Spring 上下文:
Spring 上下文是一個配置檔案,向 Spring 框架提供上下文資訊。提供了一種框架式的物件訪問方法,有些象JNDI註冊器。Context封裝包的特性得自於Beans封裝包,並新增了對國際化(I18N)的支援(例如資源繫結),事件傳播,資源裝載的方式和Context的透明建立,比如說通過Servlet容器。Spring 上下文和Bean工廠都是 bean 容器 的實現。
3.Spring AOP:
通過配置管理特性,Spring AOP 模組直接將面向方面的程式設計功能整合到了 Spring 框架中。所以,可以很容易地使 Spring 框架管理的任何物件支援 AOP。Spring AOP 模組為基於 Spring 的應用程式中的物件提供了事務管理服務。
4.Spring DAO:
JDBC DAO 抽象層提供了有意義的異常層次結構,可用該結構來管理異常處理和不同資料庫供應商丟擲的錯誤訊息。異常層次結構簡化了錯誤處理,並且極大地降低了需要編寫的異常程式碼數量(例如開啟和關閉連線)。Spring DAO 的面向 JDBC 的異常遵從通用的 DAO 異常層次結構。
5.Spring ORM:
Spring 框架插入了若干個 ORM 框架,從而提供了 ORM 的物件關係工具,其中包括 JDO、Hibernate 和 iBatis SQL Map。所有這些都遵從 Spring 的通用事務和 DAO 異常層次結構。
6.Spring Web 模組:
Web 上下文模組建立在應用程式上下文模組之上,為基於 Web 的應用程式提供了上下文。
7.Spring MVC 框架:
MVC 框架是一個全功能的構建 Web 應用程式的 MVC 實現。通過策略介面,MVC 框架變成為高度可配置的,MVC 容納了大量檢視技術,其中包括 JSP、Velocity、Tiles、iText 和 POI。
Spring 核心特點:IOC和AOP
控制反轉模式(IOC)也稱作依賴性介入(DI)的基本概念是:不建立物件,但是描述建立它們的方式。在程式碼中不直接與物件和服務連線,但在配置檔案中描述哪一個元件需要哪一項服務。容器 (在 Spring 框架中是 IOC 容器) 負責將這些聯絡在一起。在典型的 IOC 場景中,容器建立了所有物件,並設定必要的屬性將它們連線在一起,決定什麼時間呼叫方法。
Rod Johnson是第一個高度重視以配置檔案來管理Java例項的協作關係的人,他給這種方式起了一個名字:控制反轉(Inverse of Control,IoC)。後來Martine Fowler為這種方式起了另一個名稱:依賴注入(Dependency Injection),因此不管是依賴注入,還是控制反轉,其含義完全相同。
當某個Java物件(呼叫者)需要呼叫另一個Java物件(被依賴物件)的方法時,在傳統模式下通常有兩種做法
原始做法: 呼叫者主動建立被依賴物件,然後再呼叫被依賴物件的方法
簡單工廠模式: 呼叫者先找到被依賴物件的工廠,然後主動通過工廠去獲取被依賴物件,最後再呼叫被依賴物件的方法.
注意上面的主動二字,這必然會導致呼叫者與被依賴物件實現類的硬編碼耦合,非常不利於專案升級的維護。使用Spring框架之後,呼叫者無需主動獲取被依賴物件,呼叫者只要被動接受Spring容器為呼叫者的成員變數賦值即可,由此可見,使用Spring後,呼叫者獲取被依賴物件的方式由原來的主動獲取,變成了被動接受——所以Rod Johnson稱之為控制反轉。
另外從Spring容器的角度來看,Spring容器負責將被依賴物件賦值給呼叫者的成員變數——相當於為呼叫者注入它依賴的例項,因此Martine Fowler稱之為依賴注入。
AOP(Aspect Orient Programming)也就是面向切面程式設計,作為物件導向程式設計的一種補充,已經成為一種比較成熟的程式設計方式。其實AOP問世的時間並不太長,AOP和OOP互為補充,面向切面程式設計將程式執行過程分解成各個切面。
AOP專門用於處理系統中分佈於各個模組(不同方法)中的交叉關注點的問題,在JavaEE應用中,常常通過AOP來處理一些具有橫切性質的系統級服務,如日誌、事務管理、安全檢查、快取、物件池管理等,AOP已經成為一種非常常用的解決方案。
在典型的物件導向開發方式中,可能要將日誌記錄語句放在所有方法和 Java 類中才能實現日誌功能。在 AOP 方式中,可以反過來將日誌服務模組化,並以宣告的方式將它們應用到需要日誌的元件上,這樣 Java 類就不需要知道日誌服務的存在,也不需要考慮相關的程式碼。所以,用 Spring AOP 編寫的應用程式程式碼是鬆散耦合的。
Spring 優點總結
1.低侵入式設計,程式碼的汙染極低:
很多框架通過強迫應用繼承它們的類或實現它們的介面而導致應用與框架綁死,而Spring是通過spring特有的註解和通用的pojo結合。Spring的非侵入程式設計模型意味著這個類在Spring應用和非Spring應用中都可以發揮同樣的作用。Spring的元件就是普通的Java Bean,這也使得單元測試可以不再依賴容器,編寫更加容易。
2.使用模板消除樣板式程式碼:
如Spring的JdbcTemplate使得執行資料庫操作時避免傳統的JDBC樣板程式碼(建立一個資料庫連線,然後再建立一個語句物件,最後你才能進行查詢,關閉資料庫連線、語句和結果集)成為了可能。
3.獨立於各種應用伺服器:
基於Spring框架的應用,可以真正實現Write Once,Run Anywhere的承諾。
4.Spring的IoC容器降低了業務物件替換的複雜性,降低了了元件之間的耦合性:
物件的依賴關係將由系統中負責協調各物件的第三方元件在建立物件的時候進行設定,所以物件無需自行建立或管理它們的依賴關係,依賴關係將被自動注入到需要它們的物件當中去。而且如果一個物件只通過介面而不是具體實現或初始化過程來表明依賴關係,那麼這種依賴就能夠在物件本身毫不知情的情況下,用不同的具體實現進行替換。
5.Spring的AOP支援允許將一些通用任務如安全、事務、日誌等進行集中式管理:
將核心業務和系統服務分離,保持POJO的簡單性和內聚性,從而使他們各自達到更好的複用。
6.Spring的ORM和DAO提供了與第三方持久層框架的良好整合,並簡化了底層的資料庫訪問:
7.Spring的高度開放性,並不強制應用完全依賴於Spring,開發者可自由選用Spring框架的部分或全部:
當Spring不能滿足需求時, 完全可以考慮其他選擇。事實上, Spring甚至提供了與其他第三方框架和類庫的整合點, 這樣你就不需要自己編寫這樣的程式碼了。比如以前常用的SSH框架,現在常用的SSM框架
Spring包含許多專案,下面挑一些最常用的出來總結一下。
Spring MVC
Spring MVC是Spring中的基礎 Web 框架,基於模型-檢視-控制器(Model-View-Controller,MVC)模式實現,它能夠幫你構建像Spring框架那樣靈活和鬆耦合的Web應用程式。
在該框架下,一次web請求大致可以分為如下圖幾個步驟,這些劃分分離了職責,使得程式碼靈活、維護性更好。
為了使用該框架,我們首先要配置DispatchServlet,也就是前端控制器,然後啟用Spring MVC,並編寫控制器,檢視,模型等等。
其中,DispatcherServlet是Spring MVC的核心,DispatcherServlet啟動的時候,它會建立Spring應用上下文,並載入配置檔案或配置類中所宣告的bean或者自動掃描的bean,但是在Spring Web應用中,通常還會有另外一個應用上下文,這個應用上下文是由ContextLoaderListener建立的。DispatcherServlet載入包含Web元件的bean,如控制器、檢視解析器以及處理器對映,而ContextLoaderListener要載入應用中的其他bean,通常是驅動應用後端的中間層和資料層元件。
Spring MVC是一個強大靈活的Web框架。藉助於註解,Spring MVC提供了近似於POJO的開發模式,這使得開發處理請求的控制器變得非常簡單,同時也易於測試。而且Spring MVC還支援多種檢視解析器如JSP,Tiles,Thymeleaf,使得前端介面的功能更強大,編寫更容易。
Spring Web Flow
Spring Web Flow是Spring MVC的一個擴充套件, 它為基於流程的會話式Web應用(購物車或者嚮導功能)提供了支援。簡言之,它是一個流程框架,能夠引導使用者執行一系列嚮導步驟。
在Spring Web Flow中,流程是由三個主要元素定義的:狀態、轉移和流程資料。狀態( State)是流程中事件發生的地點,在流程中通過轉移的方式從一個狀態到另一個狀態,流程的當前狀況稱為流程資料。
1.行為( Action) 行為狀態是流程邏輯發生的地方
2.決策( Decision) 決策狀態將流程分成兩個方向, 它會基於流程資料的評估結果確定流程方向
3.結束( End) 結束狀態是流程的最後一站。一旦進入End狀態, 流程就會終止
4.子流程( Subflow) 子流程狀態會在當前正在執行的流程上下文中啟動一個新的流程
5.檢視( View) 檢視狀態會暫停流程並邀請使用者參與流程
轉移連線了流程中的狀態。流程中除結束狀態之外的每個狀態,至少都需要一個轉移,這樣就能夠知道一旦這個狀態完成時流程要去向哪裡。狀態可以有多個轉移,分別對應於當前狀態結束時可以執行的不同的路徑。
當流程從一個狀態進行到另一個狀態時,它會帶走一些流程資料。有時候,這些資料只需要很短的時間(可能只要展現頁面給使用者)。有時候,這些資料會在整個流程中傳遞並在流程結束的時候使用。
Spring Web Flow 可以構建會話式應用程式的Web框架,這是好的,但是感覺其配置只能用xml這個設計不太合理,尤其是當bean很多或者流程節點很多時都不好維護。
Spring Security
安全對於許多應用都是一個非常關鍵的切面,因為安全性是超越應用程式功能的一個關注點,應用系統的絕大部分內容都不應該參與到與自己相關的安全性處理中。儘管我們可以直接在應用程式中編寫安全性功能相關的程式碼,但更好的方式還是將安全性相關的關注點與應用程式本身的關注點進行分離,作為系統的一個切面。Spring Security就是通過AOP和Filter來為應用程式實現安全性的。
使用Servlet規範中的Filter保護Web請求並限制URL級別的訪問。Spring Security還能夠使用Spring AOP保護方法呼叫——藉助於物件代理和使用通知,能夠確保只有具備適當許可權的使用者才能訪問安全保護的方法。
Spring Security非常靈活,能夠基於各種資料儲存來認證使用者。它內建了多種常見的使用者儲存場景,如記憶體、關係型資料庫以及LDAP。但我們也可以編寫並插入自定義的使用者儲存實現。
當為瀏覽器渲染HTML內容時,你可能希望檢視中能夠反映安全限制和相關的資訊。一個簡單的樣例就是渲染使用者的基本資訊( 比如顯示“您已經以……身份登入”)。或者你想根據使用者被授予了什麼許可權,有條件地渲染特定的檢視元素。Spring Security本身提供了一個JSP標籤庫,而Thymeleaf通過特定的方言實現了與Spring Security的整合。藉助於這些,可以很容易的實現對檢視的保護。
Spring Data
Spring Data 是為了簡化構建基於 Spring 框架應用的資料訪問技術,包括關聯式資料庫、NoSQL、Map-Reduce 框架、雲資料服務等等,旨在提供一種通用、統一的編碼模式(但是並不是程式碼完全一樣),使得在Spring中使用任何資料庫都變得非常容易。
Spring Data作為Spring Source的其中一個父專案,旨在統一和簡化對各型別持久化儲存,而不拘泥於是關係型資料庫還是NoSQL資料儲存。
目前的Spring Data 包含如下的模組(或者說子專案):
Spring Data Commons
Spring Data JPA
Spring Data KeyValue
Spring Data LDAP
Spring Data MongoDB
Spring Data Gemfire
Spring Data REST
Spring Data Redis
Spring Data for Apache Cassandra
Spring Data for Apache Solr
Spring Data Couchbase (community module)
Spring Data Elasticsearch (community module)
Spring Data Neo4j (community module)
無論是哪種持久化儲存,資料訪問物件(DAO,即Data Access Objects)通常都會提供對單一域物件的CRUD(建立、讀取、更新、刪除)操作、查詢方法、排序和分頁方法等。Spring Data則提供了基於這些層面的統一介面(CrudRepository,PagingAndSortingRepository)以及對持久化儲存的實現。
你可能接觸過某一種Spring模型物件——比如JdbcTemplate——來編寫訪問物件的實現。但是在基於Spring Data的資料訪問物件,我們只需定義和編寫一些查詢方法的介面(基於不同的持續化儲存, 定義有可能稍有不同),Spring Data會在執行時間生成正確的實現。
然而一些Spring Data子專案,如Spring Data Redis和Spring Data Riak都只是提供模板,這是由於其相應的資料儲存都只支援非結構化的資料,而不適用於物件的對映和查詢。
Spring Boot
Spring誕生時是Java企業版(Java Enterprise Edition, JEE,也稱J2EE)的輕量級代替品。無需開發重量級的Enterprise JavaBean(EJB),Spring為企業級Java開發提供了一種相對簡單的方法。
雖然Spring的元件程式碼是輕量級的,但它的配置卻是重量級的。一開始,Spring用XML配置,而且是很多的XML配置,即使後來有基於註解的改善,我們依然難逃大量配置的魔爪。而Spring Boot讓這一切成為了過去,如果說Spring的目的是簡化程式的開發,那麼Spring Boot就是為了簡化Spring本身的開發。
Spring Boot依賴於自動配置技術將Spring應用中樣板式的配置移除掉,這樣就能讓我們免受於一大堆的配置之苦,更加專注於業務功能。Spring Boot同時還提供了多個Starter專案,拿來即可用,極大地簡化了程式設計任務。
它提供了四個主要的特性,能夠改變開發Spring應用程式的方式:
1.Spring Boot Starter:它將常用的依賴分組進行了整合,將其合併到一個依賴中,這樣就可以一次性新增到專案的Maven或Gradle構建中,這裡可以找到目前所有的starter專案。
2.自動配置:Spring Boot的自動配置特性利用了Spring 4對條件化配置的支援,合理地推測應用所需的bean並自動化配置它們,減少了你自己需要配置的數量。
3.命令列介面(Command-line interface,CLI):Spring Boot的CLI發揮了Groovy程式語言的優勢,並結合自動配置進一步簡化Spring應用的開發。
4.Actuator:它為Spring Boot應用新增了一定的管理特性。
Spring Cloud
在進入主題之前,首先來看看微服務,簡單說來就是將原本單個獨立的大系統拆分為分散式的多個小型的服務,這些小型服務各自獨立執行,他們通過HTTP和RestFul API進行通訊。
一個微服務一般完成某個特定的功能,比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用,都有自己的業務邏輯和介面卡。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI,執行時,每一個例項可能是一個雲VM或者是Docker容器。
微服務具有分散式系統的特性,如服務發現,負載均衡,故障轉移,多版本,灰度升級,服務降級,分散式跟蹤。
Spring Cloud是一套完整的分散式系統解決方案,它的子專案涵蓋了所有實現分散式系統所需要的基礎軟體設施(包括配置管理、服務治理、智慧路由、全域性鎖等等)。基於Spring Boot,Spring Boot做較少的配置,便可成為Spring Cloud中的一個微服務,使用Spring Cloud的開發者可以快速的啟動服務或構建應用、同時能夠快速和雲平臺資源進行對接,使得開發部署極其簡單。
Spring Cloud專注於提供良好的開箱即用經驗的典型用例和可擴充套件性機制覆蓋:
分散式/版本化配置:Spring Cloud Config
服務註冊和發現:Netflix Eureka 或者 Spring Cloud Eureka(對前者的二次封裝)
路由:Spring Cloud Zuul 基於 Netflix Zuul
service - to - service呼叫:Spring Cloud Feign
負載均衡:Spring Cloud Ribbon 基於 Netflix Ribbon 實現
斷路器:Spring Cloud Hystrix
分散式訊息傳遞:Spring Cloud Bus
關於Spring的核心知識點總結了20多頁pdf,今天分享給大家。歡迎大家關注我的公眾號【程式設計師追風】,文章都會在裡面更新,整理的資料也會放在裡面。
最後
總結了一大堆,感覺Spring Boot是趨勢,畢竟效率是王道。然後就是Spring Data的各個專案,因為如今的資料來源是越發的豐富。最後,近幾年微服務的概念挺火的,所以Spring Cloud也要多多瞭解。