早上起來佔個坑，晚上整理。

依賴注入DI(dependency injection)：

誰依賴誰？誰注入誰？注入什麼？

呼叫類依賴功能類。

容器注入呼叫類。

注入了功能類的例項。

控制反轉Ioc(inversion of control):

誰控制誰？反轉了什麼？正轉是什麼？

ioc容器控制例項的建立和管理、注入。

反轉了例項的建立方，由呼叫類轉移到Ioc容器中。

正轉是在呼叫類中主動建立功能類的例項，控制它的生命週期。

依賴注入和控制反轉的區別？

依賴注入和控制反轉不是一門技術，而是一種通過注入依賴物件來實現解耦的設計思想，是程式設計的一個基本設計原則。

所以，對它們沒有明確的技術界限的定義，仁者見仁智者見智，各自有各自的理解。重點是其中的注入依賴物件的解耦思想。

這種設計原則，設計思想初期從控制權的角度稱作Ioc，但2004年一個技術大牛認為控制反轉不太貼切，提出了依賴注入這個概念。其實無論依賴注入還是控制反轉，他們只是對同一設計思想，在不同方面理解下的稱呼而已，並無實質區別。

spring 的Ioc容器在這一設計原則下做了什麼？

將呼叫類所有依賴的物件通過注入的方式賦予呼叫類，實現了最大程度的解耦合（呼叫類只需認識功能類的介面和Ioc容器）。

class Audi implements ICar{
}
class Person{
ICar car;
...
}
//通過構造方法注入
ICar car1=new Audi();
Person p1=new Person(car1); 
p1.drive();
或
//通過屬性注入
ICar car2=new Audi();
Person p2=new Person();
p2.setCar(car2);
p2.drive();

但是這樣雖然不必再讓呼叫類去認識所有的ICar的實際類，只需要認識一個ICar介面，降低了耦合度，但產生了一個問題，

建立一個Person例項時，我還需要建立一個ICar的例項，然後手動注入Person例項，如果Person類還依賴於許多類，那麼當建立一個Person例項就需要同時建立許多個功能類例項，然後再手動注入Person中，這樣太累了，，，

而我又想用這種設計方法來降低我的程式碼耦合度，又不想建立一個例項這麼麻煩地做這麼多工作，怎麼辦呢，，，

spring Ioc登場，框架就是來為開發者省時省力的（學框架雖然麻煩，但學會它會給你省去更多的麻煩，超值！！！安慰自己）

通過spring Ioc容器，我們只需在Beans中配置類的例項化引數，和他們之間的依賴關係，就可以像傳統地開發方式一樣輕鬆地建立類地例項物件了

ApplicationContext context=new ClassPathXmlApplicationContext();

Person p1=context.getBean("p1");//通過id建立

Person p2=context.getBean(Person.class);//通過型別建立

關於如何通過配置，選擇不同的初始化方法，注入類的屬性引數、依賴物件，可以通過進一步學習掌握啦。

（其實想想spring Ioc的容器管理和mybatis的sql管理相似，先配置xml檔案、建立框架的工廠，工廠通過id或其他引數呼叫具體例項，核心思想很相似。看得多了大致都是這樣）

所以，：

依賴注入和控制反轉只是對這同一種設計原則的不同稱呼，搞明白這種設計思想的原理、用處、優點、精妙之處後，

其明確，界限分明的定義如何闡述就不重要了，在你心中就有了自己的一套解釋。