希望給你3-5分鍾的碎片化學習，可能是坐地鐵、等公交，積少成多，水滴石穿，謝謝關注。
從UML來理解依賴
1.1什么是依賴
我們先看下圖
可以簡單理解，一個HomeController類使用到了DBContext類，而這種關系是有偶然性，臨時性，弱關系的，但是DBContext的變化會影響到HomeController
1.2顯示依賴和隱式依賴
先看顯示依賴代碼：
顯示依賴通過構造函數，很清楚的描述了HomeController類都依賴了哪些對象，這樣就可以很好的管理這些依賴。而隱式依賴的缺點剛好就是顯示依賴的優點。我們看下面的隱式依賴：
如果一個類有上千行代碼，到處都充斥着該類型的代碼，這些代碼就像隱藏的病毒一樣，無處不在，可以想象后續的變化和修改是多么的恐怖。
1.3依賴倒置
依賴倒置的概念其實很簡單，一句話就講完了：我們要依賴抽象，而不依賴具體實現。什么是抽象？比如接口，抽象類就是。
依賴抽象的目的是什么？封裝變化！因為所有實現接口的實現都可以互相替換。
如上圖所示，當數據庫DapperUserRepository切換到EfUserRepository，對HomeController類可以無需任何修改，就可以平滑切換過去。反之，則更改的面就會非常大。
再看下面的代碼，OrderController依賴接口IUserRepository就是依賴倒置的表現。
從單元測試來理解
也許你會說，我的變化沒有那么頻繁，不需要那么麻煩。那么你是否考慮過，有可能自己的代碼需要進行單元測試？如果存在這種可能，那么依賴注入是你必須要做的事。
2.1控制反轉
我們再看下面這個代碼的問題
雖然OrderController依賴的是接口IUserRepository，滿足依賴倒置原則，但是構造函數卻依賴的是具體實現類UserRepository，這種做法屬於硬編碼，仍然無法滿足未來變化帶來的修改，怎么辦？接下來我們來講控制反轉這個相對難以理解的概念。
先說反轉，到底反轉的是什么？我們知道OrderController依賴的對象UserRepository是在構造函數內的生成的。如何能夠把該對象的生成交給外部去決定生成呢？可以的！這種轉移對象生成的方式就是控制反轉。
簡而言之，反轉的是控制權，即依賴對象生成的控制權。是自己決定生成還是交由別人去決定生成。
所以上面的代碼，修改如下：
以上的代碼才達到真正的控制反轉，UserRepository對象的生成完全交由外部進行控制，交給變化去控制。
這樣有什么好處呢？交給外部生成的最大好處是想要生成什么對象可以自由控制，這樣還是為了將來對象生成的可替換，比如數據庫訪問對象的變更；單元測試的實現類替換等等。
2.2單元測試
有了上面的控制反轉，我們的單元測試就方面很多了。
我們可以看到，在數據庫無法連接的時候，我們可以使用MemoryUserRepository進行替換單元測試，非常方便。
我是.NET架構師張飛洪，入行10年有余，人不堪其憂，吾不改其樂，謝謝您關注我的頭條號