這邊要先理解的是,Java是一個物件導向的程式語言,所有的邏輯都會經由物件來完成。
為了說明IoC及DI,我們先忘記前面提到的架構。假設我們把分工簡化到極致,全部都在一個程式內完成,那麼主程式流程大概會如下:
1.建立一個監聽事件的物件: eventHandler
監聽事件
。2.建立一個剖析事件的物件,從中取出必要資料及使用者訊息: eventProcesser
。
處理事件
。3.建立一個回應事件的物件,replyHandler
回應事件
。上面的流程,我們可以更簡化成兩個部分:
1.商業邏輯
2.控制商業邏輯所需要的依賴
eventHandler
,並且設定好要監聽的IP、Port、驗證資訊,以及要檢查的格式。eventProcesser
,並且設定好剖析完成後,要輸出的格式。replyHandler
,並且設定好要回應的目的端資訊。控制商業邏輯所需要的依賴
,就是IoC的控制
(Control)。講的就是: 在執行商業邏輯的過程中,設定並且實例化所需要的物件。
Inversion這個單字翻成反轉可能比較難懂,實際上他的意思比較接近於外包
,也就是,把設定並且實例化所需要的物件這項工作,通通外包給一個跟商業邏輯無關的第三方程序
。經由IoC化以後的程式流程會包含兩個程序,大概會是這樣:
1.第三方程序
eventHandler
,並且設定好要監聽的IP、Port、驗證資訊,以及要檢查的格式。eventProcesser
,並且設定好剖析完成後要輸出的格式。replyHandler
,並且設定好要回應的目的端資訊。2.等第三方程序把所有要用到的物件都做好以後,開始執行商業邏輯的主流程:
eventHandler
並執行listen()。eventProcesser
並執行process()。replyHandler
並執行reply()。簡潔的主流程
設定並且實例化所需要的物件
這項工作給外包出去了,所有相關程式碼都不會在主流程看到,而是寫在第三方程序。控制依賴
的程式碼干擾解掉主流程與依賴的耦合,方便依賴抽換
控制依賴
這件事不在主流程內,當我們要抽換依賴的實作時,可以完全不用改變主流程,直接要求第三方抽換需要的依賴即可。不需要改變主要的商業邏輯
。容器(Container)作為第三方程序
,來託管所有需要的依賴實例
,並且在需要時,透過類別的建構子(Constructor)、方法(setter Function)、或者屬性(Field),來將實例傳遞給需要的對象。Spring Framework提供了容器,來託管並實例化所有需要的物件。
在Spring中:
Bean
代表了所有商業邏輯所需要的物件
。Application Context
就是用來管理所有實例的容器,由它負責創建、配置、管理和銷毀應用程序中的 Beans:
圖: 在Spring中,容器就是Application context,負責託管Beans
Spring Web MVC
, 與資料庫對接的Spring Data
等等。Spring Boot則是其中一個子項目,他的目的是先幫開發者做好一些繁雜的設定,讓開發者得以更專精於主要商業邏輯的開發。配置方式
使用簡單的Annotation註解,來配置並組合成商業邏輯
簡化執行方式
.WAR
文件,並部署到外部應用伺服器(如 Tomcat)。java -jar 程式名稱.jar
來執行程式。提供Starter POM
pom.xml
設定檔加入spring-boot-starter-data-mongodb這個starter,就會包含所有已經選好的依賴,而在Spring Framework則需要自己逐個把依賴加入。https://docs.spring.io/spring-framework/reference/core/beans/basics.html
https://spring.io/projects/spring-boot
https://docs.spring.io/spring-boot/reference/using/structuring-your-code.html
https://docs.google.com/document/d/1yt8QwUY-FPECg8WCxzM7KXeg5oRyTjnXAQ-qEM1j07E/edit#heading=h.b89bcmyb8z3n