Spring控制反轉(IoC)的理解
Spring框架的核心就是控制反轉(Inversion of Control)和依賴注入(Dependency Injection)，通過這兩方面來實現松耦合。
使用IoC，對象是被動的接受依賴類，而不是自己主動的去找。容器在實例化的時候主動將它的依賴類注入給它。可以這樣理解：控制反轉將類的主動權轉移到接口上，依賴注入通過xml配置文件在類實例化時將其依賴類注入。
依賴類(Dependency)是通過外部(xml)來注入的，而不是由使用它的類(Business)來自己制造，這就是依賴的注入。另一方面，Business對類Dependency的依賴轉移到對接口IDependency的依賴，控制權由類轉移到了接口，即由"實現"轉移到"抽象"中。這就是控制反轉。
使用IoC，對象是被動的接受依賴類，而不是自己主動的去找。容器在實例化的時候主動將它的依賴類注入給它。可以這樣理解：控制反轉將類的主動權轉移到接口上，依賴注入通過xml配置文件在類實例化時將其依賴類注入。
控制反轉即IoC (Inversion of Control)，它把傳統上由程序代碼直接操控的對象的調用權交給容器，通過容器來實現對象組件的裝配和管理。所謂的“控制反轉”概念就是對組件對象控制權的轉移，從程序代碼本身轉移到了外部容器。
依賴注入(Dependency Injection)和控制反轉(Inversion of Control)是同一個概念。具體含義是:當某個角色(可能是一個Java實例，調用者)需要另一個角色(另一個Java實例，被調用者)的協助時，在傳統的程序設計過程中，通常由調用者來創建被調用者的實例。但在Spring里，創建被調用者的工作不再由調用者來完成，因此稱為控制反轉;創建被調用者實例的工作通常由Spring容器來完成，然后注入調用者，因此也稱為依賴注入。
簡而言之：所謂控制反轉就是應用本身不負責依賴對象的創建及維護，依賴對象的創建及維護是由外部容器負責的。這樣控制權就由應用轉移到了外部容器，控制權的轉移就是所謂反轉；所謂依賴注入就是指：在運行期，由外部容器動態地將依賴對象注入到組件中。
傳統編程和IoC的對比
傳統編程：決定使用哪個具體的實現類的控制權在調用類本身，在編譯階段就確定了。
IoC模式：調用類只依賴接口，而不依賴具體的實現類，減少了耦合。控制權交給了容器，在運行的時候才由容器決定將具體的實現動態的“注入”到調用類的對象中。
應用控制反轉，對象在被創建的時候，由一個調控系統內所有對象的外界實體將其所依賴的對象的引用傳遞給它。也可以說，依賴被注入到對象中。所以，控制反轉是，關于一個對象如何獲取他所依賴的對象的引用，這個責任的反轉。
IoC核心理念：
1.在類當中不創建對象，在代碼中不直接與對象和服務連接
2.在配置文件中描述創建對象的方式，以及各個組件之間的聯系
3.外部容器通過解析配置文件，通過反射來將這些聯系在一起
The Hollywood principle：Don’t call us,we’ll call you.
即，所有組件都是被動的、不主動聯系（調用）外部代碼，
要等著外部代碼的調用--------所有的組件的初始化和相互調用都由容器負責實現。
簡單的說，就是整個程序之間的關系，都由容器來控制:將程序的控制權反轉給容器,就是所謂的外轉
而在我們傳統代碼中，由程序代碼直接控制
優缺點：
IoC最大的好處是什么？
因為把對象生成放在了XML里定義，所以當我們需要換一個實現子類將會變成很簡單（一般這樣的對象都是實現于某種接口的），只要修改XML就可以了，這樣我們甚至可以實現對象的熱插拔（有點象USB接口和SCSI硬盤了）。
IoC最大的缺點是什么？
（1）生成一個對象的步驟變復雜了（事實上操作上還是挺簡單的），對于不習慣這種方式的人，會覺得有些別扭和不直觀。
（2）對象生成因為是使用反射編程，在效率上有些損耗。但相對于IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某對象的生成對效率要求特別高。
（3）缺少IDE重構操作的支持，如果在Eclipse要對類改名，那么你還需要去XML文件里手工去改了，這似乎是所有XML方式的缺憾所在。
IOC的意思是控件反轉也就是由容器控制程序之間的關系，把控件權交給了外部容器，之前的寫法，由程序代碼直接操控，而現在控制權由應用代碼中轉到了外部容器，控制權的轉移是所謂反轉。