Spring的IOC控制反轉和DI依賴注入到底有什麼意義，到底有什麼好處，概念怎麼理解

• 2019 年 10 月 8 日
• 筆記

1.IOC和DI概念意義和實現 : 由於控制反轉和依賴注入的概念比較難，我們拿下面這個例子來講解概念。我們過去在學mvc時，都是在controller里實例化出一個service的對象，之後再使用它。實例化對象的控制權在我們手裡（所謂正序）。現在當我們應用spring容器時，實例化的控制權不在我們手裡了，控制權反轉了，控制權利跑到spring容器手裡了。@Service的意思就是把實現這個介面類型的類實例化以後放在spring容器當中，供將來使用（不懂就看我的例子）。（注意，如果有兩個類都實現了介面，而且都有@Service關鍵字，就會報錯，容器不知道將來用誰）。 既然@Service是實例化的意思，@Resource就是引用實例的作用。控制反轉講了，下面講講依賴注入。還拿下面這個例子來講。controller想幹活就需要引用service，專業一點講，叫依賴service。換句話說，controller想幹活，需要把它依賴的service注入進來，這叫依賴注入。靠什麼呢？就靠上述@Resource或@Autowired的關鍵字。 有同學說，這折騰什麼呢?有什麼意義啊？ioc到底有什麼好處？還拿咱們例子說事。如果現在新的需求下來，需要改動我們的service，連名字帶包名，都得改，而且還要求controller不能改。這在過去，用new關鍵字實例化時，controller是肯定要改動的，因為是硬編碼（new Service）。而現在是用控制反轉，你看一下程式碼，果然即使service名字都變了的情況下，controller都不用改，程式依然運行良好。（順便提一句，想達到這種效果必須用介面編程，見我們的例子。不用介面編程，雖然程式還是能夠通，但實現不了controller不變的目標，即，達不到controller和service像現在用介面編程這樣高度的松耦合。介面完全把依賴別人者和被依賴者分開了。依賴別人者只對介面說話，連被依賴者改變與否都不知道。達到了高度的松耦合。只要介面不改，controller就不改，介面就像合約，我講過，在介面那章，記得嗎？）一句話，控制反轉的好處就是，當與介面編程同時使用時，依賴別人者不會因被依賴者改變而改變，達到了高度的松耦合。

更多請見下節：https://blog.csdn.net/mark_to_win/article/details/88695929