IOC控制反轉另外一種說法叫DI，即依賴注入，是利用反射機制，它並不是一種技術實現，而是一種設計思想。在任何一個有實際開發意義的程序項目中，我們會使用很多類來描述它們特有的功能，並且通過類與類之間的相互協作來完成特定的業務邏輯。這個時候，每個類都需要負責管理與自己有交互的類的引用和依賴，代碼將會變的異常難以維護和極度的高耦合。
而IOC的出現正是用來解決這個問題，我們通過IOC將這些相互依賴對象的創建、協調工作交給spring容器去處理，每個對象只需要關注其自身的業務邏輯關系就可以了。在這樣的角度上來看，獲得依賴的對象的方式，進行了反轉，變成了由spring容器控制對象如何獲取外部資源（包括其他對象和文件資料等等）。
通俗點說許多應用都是通過彼此間的相互合作來實現業務邏輯的，如類A要調用類B的方法，以前我們都是在類A中，通過自身new一個類B，然后在調用類B的方法，現在我們把new類B的事情交給spring來做，在我們調用的時候，容器會為我們實例化。
引入IOC的目的：脫開、降低類之間的耦合；倡導面向接口編程、實施依賴倒換原則；提高系統可插入、可測試、可修改等特性。
使用IOC框架應該注意什么：使用IOC框架產品能夠給我們的開發過程帶來很大的好處，但是也要充分認識引入IOC框架的缺點，做到心中有數，杜絕濫用框架。第一、軟件系統中由於引入了第三方IOC容器，生成對象的步驟變得有些復雜，本來是兩者之間的事情，又憑空多出一道手續，所以，我們在剛開始使用IOC框架的時候，會感覺系統變得不太直觀。所以，引入了一個全新的框架，就會增加團隊成員學習和認識的培訓成本，並且在以后的運行維護中，還得讓新加入者具備同樣的知識體系。第二、由於IOC容器生成對象是通過反射方式，在運行效率上有一定的損耗。如果你要追求運行效率的話，就必須對此進行權衡。第三、具體到IOC框架產品(比如：Spring)來講，需要進行大量的配制工作，比較繁瑣，對於一些小的項目而言，客觀上也可能加大一些工作成本。第四、IOC框架產品本身的成熟度需要進行評估，如果引入一個不成熟的IOC框架產品，那么會影響到整個項目，所以這也是一個隱性的風險。
我們大體可以得出這樣的結論：一些工作量不大的項目或者產品，不太適合使用IOC框架產品。另外，如果團隊成員的知識能力欠缺，對於IOC框架產品缺乏深入的理解，也不要貿然引入。最后，特別強調運行效率的項目或者產品，也不太適合引入IOC框架產品，像WEB2.0網站就是這種情況。
AOP面向切面編程是利用代理模式，是OOP的延續和補充，意思是面向方面編程，核心思想是將業務邏輯中與類不相關的通用功能切面式的提取分離出來，讓多個類共享一個行為，一旦這個行為發生改變，不必修改類，而只需要修改這個行為即可。
面向切面編程往往被定義為促使軟件系統實現關注點的分離的技術。系統是由許多不同的組件所組成的，每一個組件各負責一塊特定功能。除了實現自身核心功能之外，這些組件還經常承擔着額外的職責。例如日志、事務管理和安全這樣的核心服務經常融入到自身具有核心業務邏輯的組件中去。這些系統服務經常被稱為橫切關注點，因為它們會跨越系統的多個組件。
AOP的優點：利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用性，同時提高了開發的效率。
主要功能：日志記錄、事務處理、異常處理、安全控制和性能統計方面。
主要意圖：將日志記錄，性能統計，安全控制，事務處理，異常處理等代碼從業務邏輯代碼中划分出來，通過對這些行為的分離，我們希望可以將它們獨立到非指導業務邏輯的方法中，進而改變這些行為的時候不影響業務邏輯的代碼。
核心思想：是將業務邏輯中與類不相關的通用功能切面式的提取分離出來，讓多個類共享一個行為，一旦這個行為發生改變，不必修改類，而只需要修改這個行為即可。
OOP與AOP的區別： 1、面向目標不同：簡單來說OOP是面向名詞領域，AOP面向動詞領域。2、思想結構不同：OOP是縱向結構，AOP是橫向結構。3、注重方面不同：OOP注重業務邏輯單元的划分，AOP偏重業務處理過程的某個步驟或階段。兩者之間是一個相互補充和完善的關系。