① 解釋Spring中IOC, DI, AOP
ioc就是控制翻轉或是依賴注入。通俗的講就是如果在什麼地方需要一個對象，你自己不用去通過new 生成你需要的對象，而是通過spring的bean工廠為你長生這樣一個對象。
aop就是面向切面的編程。比如說你每做一次對資料庫操作，都要生成一句日誌。如果，你對資料庫的操作有很多類，那你每一類中都要寫關於日誌的方法。但是如果你用aop，那麼你可以寫一個方法，在這個方法中有關於資料庫操作的方法，每一次調用這個方法的時候，就加上生成日誌的操作。
說的不是很清晰，多寫多看就能明白了。
② spring ioc和di的區別
IOC是個更寬泛的概念，DI是更具體的。引用鄭燁的一篇博客，我眼中的Spring
Dependency Injection
原來，它叫IoC。
Martin Flower發話了，是個框架都有IoC，這不足以新生容器反轉的「如何定位插件的具體實現」，於是，它有了個新名字，Dependency Injection。
其實，它就是一種將調用者與被調用者分離的思想，Uncle Bob管它叫DIP（Dependency Inversion Principle），並把它歸入OO設計原則。
同Spring相比，它更早進入我的大腦。一切都是那麼朦朧，直至Spring出現。
慢
慢的，我知道了它還分為Interface Injection（type 1），Setter Injection（type
2），Constructor Injection（type 3）。Martin Flower那篇為它更名的大作讓我心目關於它的一切趨於完整。
在Spring中，它是一切的基礎。Spring的種種優勢隨之而來。
於我而言，它為我帶來更多的是思維方式的轉變，恐怕以後我再也無法寫出那種一大塊的全功能程序了。
③ 怎樣在php中更好的實現解耦
二、實現解耦兩種方式
對於傳統的PHP框架，我們很難把這個框架里某個需要的組件提取出來單獨使用。因為這個組件可能會用到Logger對象、Config對象等等其他別的什麼對象，而且這些外部依賴的代碼是寫死在源代碼里的。有時候想單獨使用框架內部的某個功能，不得不寫大量的移植代碼。要實現一個高度解耦的PHP框架，需要參考一下服務定位和依賴注入兩種模式。在Zend framework2.0里，底層實現了DI，上層又按照SL封裝了一個ServiceManager。
有人說Service Locator是一種反模式，因為在代碼中使用Service Locator也算是一種隱含的外部依賴關系。其實這是矯情，難道在代碼中使用IoC容器就不是外部依賴么？問題在於在恰當的場合使用恰當的模式。
首先要搞清楚代碼究竟是屬於「調用者」還是屬於「被調用者」。作為「被調用者」，比如某個模塊，可以預見到代碼會被使用在不同場合，當然是對外部的耦合越小越好，對於自己所需要的外部介面，完全可以依賴外部「調用者」來被動注入；但對於的「調用者」代碼來說，作為最終的應用層代碼，需要做到統籌全局，當然是不可避免地要直接與各個組件產生耦合了。
至於什麼時候用依賴注入，什麼時候用服務定位，我個人的看法著這樣的：編寫組件時，最好使用依賴注入模式，特別是當這個組件可能被用於不同的項目工程中時；編寫應用層代碼、或者項目平台相關性強的組件時，可以使用服務定位模式。另外，依賴注入的外部介面對於組件來說應該是強依賴的，組件缺少這些外部介面是無法獨立運行的；服務定位取得的外部介面應該是弱依賴的，在缺少介面的情況下，組件也能勉強運行。舉個例子：用戶模型組件在完成用戶注冊的過程中，會用到兩個外部介面，一個是數據訪問層介面，用於將用戶信息保存到資料庫或別的永久儲存介質里，另一個是郵件發送介面，用於向用戶郵箱發送一封注冊確認信。其中數據訪問層介面對於用戶模型組件是強依賴關系，後者缺了前者將無法正常運行；而郵件發送介面對於用戶模型組件是弱依賴關系，沒有這個介面也能完成用戶注冊過程，只不過會產生一些警告信息。
④ 可以實現ioc模式的方法有哪些
di就是ioc，前者叫依賴注入 dependency injection, 後者是控制反轉Inverse of Control， spring的ioc是用aop的方式進行di實現的，往大了方向，模式角度講，aop是用動態代理模式實現的。
不過你說地也對，可以把ioc認為是在解耦，但是我覺得不能畫等號，感覺上解耦有其他方式，我估計你想要的其實是解耦方式，當然它是有很多實現方式的，你了解一下java的那些個模式就知道了，通常一個模式就對應於你想的一個方式。比如asm這個框架，（PS：asm是java位元組碼框架的一種,這類框架還有javassist,和一個bcel,主要是用來直接操作.class文件，動態改變類的屬性及行為，我只研究過asm) 它用的解耦模式叫做訪問者模式，這個方式的特點是你實現其提供的介面後，你的業務邏輯應寫在需要實現的介面方法體內，它通過讀位元組碼而找到類的屬性，方法，註解等等東西會通過調你實現的該方法以參數傳給你。開始我很納悶，這種方式很費解的，一改我們的平常思維：調框架提供的某個類的方法，經過它方法的處理得出的返回值是我們需要的值，而它這個，你需要的值是通過參數傳進來的，不過後來悟出來了，給你留個懸念吧。想想為什麼。
當然你想要的東西應該就是模式。網上搜羅吧。應該是26種，記不清了，不過模式的旨意都大同小異：提高代碼重用率；解耦
⑤ 什麼是AOP、IOC他們的作用是什麼
什麼是IoC
Ioc—Inversion of Control，即「控制反轉」，不是什麼技術，而是一種設計思想。在Java開發中，Ioc意味著將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確「誰控制誰，控制什麼，為何是反轉（有反轉就應該有正轉了），哪些方面反轉了」，那我們來深入分析一下：
控制是什麼：傳統Java SE程序設計，我們直接在對象內部通過new進行創建對象，是程序主動去創建依賴對象；而IoC是有專門一個容器來創建這些對象，即由Ioc容器來控制對象的創建；誰控制誰？當然是IoC 容器控制了對象；控制什麼？那就是主要控制了外部資源獲取（不只是對象包括比如文件等）。
為何是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙創建及注入依賴對象；為何是反轉？因為由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。
IoC能做什麼
IoC不是一種技術，只是一種思想，一個重要的面向對象編程的法則，它能指導我們如何設計出松耦合、更優良的程序。傳統應用程序都是由我們在類內部主動創建依賴對象，從而導致類與類之間高耦合，難於測試；有了IoC容器後，把創建和查找依賴對象的控制權交給了容器，由容器進行注入組合對象，所以對象與對象之間是鬆散耦合，這樣也方便測試，利於功能復用，更重要的是使得程序的整個體系結構變得非常靈活。
其實IoC對編程帶來的最大改變不是從代碼上，而是從思想上，發生了「主從換位」的變化。應用程序原本是老大，要獲取什麼資源都是主動出擊，但是在IoC/DI思想中，應用程序就變成被動的了，被動的等待IoC容器來創建並注入它所需要的資源了。
IoC和DI
DI—Dependency Injection，即「依賴注入」：是組件之間依賴關系由容器在運行期決定，形象的說，即由容器動態的將某個依賴關系注入到組件之中。依賴注入的目的並非為軟體系統帶來更多功能，而是為了提升組件重用的頻率，並為系統搭建一個靈活、可擴展的平台。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業務邏輯，而不需要關心具體的資源來自何處，由誰實現。
註：如果想要更加深入的了解IoC和DI，請參考大師級人物Martin Fowler的一篇經典文章《Inversion of Control Containers and the Dependency Injection pattern》，原文地址：http://www.martinfowler.com/articles/injection.html。
AOP：面向切面編程
什麼是AOP：
概念：在軟體業，AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，通過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。AOP是OOP的延續，是軟體開發中的一個熱點，也是Spring框架中的一個重要內容，是函數式編程的一種衍生范型。利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用性，同時提高了開發的效率。（網路）
簡單的說：就是將程序中重復的代碼抽取出來，在需要執行的時候，使用動態代理的技術，在不修改源碼的基礎上，對我們的已有方法進行增強。
AOP的作用和優勢：
作用：從定義中來看，就是為了在程序運行期間，不修改源碼對已有方法進行增強。
優勢：減少重復代碼 提交了開發效率 維護方便
實現方式： 就是動態代理的技術
具體的作用：實現事務的控制 日誌 和 安全模塊
想系統的學習編程可以來我這看看，希望對您有所幫助！~
⑥ ioc有兩種實現機制 ioc是什麼 為什麼要ioc
di就是ioc，前者叫依賴注入 dependency injection, 後者是控制反轉Inverse of Control， spring的ioc是用aop的方式進行di實現的，往大了方向，模式角度講，aop是用動態代理模式實現的。 不過你說地也對，可以把ioc認為是在解耦
⑦ 面試題：請你說一說Spring中IOC和DI的含義應該怎麼回答
ioc就是控制翻轉或是依賴注入。
DI（Dependency Injection，依賴注入）
⑧ 為什麼在python中是ioc / di不常見
為什麼在python中是ioc / di不常見
IOC是控制反轉,所謂反轉是指應用本身並不負責依賴對象的創建和維護,而把這個任務交給第三方即Spring去處理,這是將創建對象的權利交給第三方,控制反轉就是控制權的轉移
DI是依賴注入.依賴注入,是指運行期間,Spring動態的將依賴對象注入到組件中。
當IOC容器啟動時，容器負責創建容器內的所有對象;
根據配置信息形成對象之間的依賴關系；
也就是說讓別人(ioc)為你服務。這是核心。
⑨ Spring中控制反轉（IoC）/依賴注入（DI）說的是一回事嗎只是名字不同新出的Spring3里是哪一個
同一件事，強調的內容不同而已。IoC控制反轉，強調容器的作用，用於組織或控制容器內bean的運行。DI依賴注入，強調Bean需要外部注入才能正常運轉。相對地說做容器框架的（比如Spring)當然強調控制了，怎麼更好的控制別的Bean的運行，相反做模塊的，當然強調注入了，我到底需要依賴注入什麼。
其實本質上，主要優勢就是通過介面解耦合，然後使用容器配置文件，組織bean的運行，擴展性更強，也便於靈活地用於大粒度的模塊，組件級編程。Spring已經是比較成熟的容器框架，所以大多數人的設計，主要還是考慮到底需要依賴注入什麼。
⑩ 怎麼樣使用php的laravel框架快速集成微信登錄
1. 安裝php_weixin_provider
在項目下運行composer require thirdproviders/weixin，即可完成安裝。安裝成功後，在項目的vendor目錄下應該能看到php_weixin_provider的庫文件：
image
2. 配置微信登錄的參數
一共有7個參數可以配置，分別是：
client_id：對應公眾號創建的應用appid
client_secret：對應公眾號創建的應用appid
redirect：對應微信授權成功後的回調地址
proxy_url：對應微信授權的代理服務地址（其作用可閱讀這篇文章了解）
device：區別是PC端微信登錄還是移動端微信登錄，默認值為pc，如果是移動端，可設置為空
state_cookie_name：授權鏈接中會包含隨機的state參數，這個參數在微信回調的時候會原封不動的返回來，屆時可通過驗證state參數是否與授權鏈接中傳入的參數相同，來判斷請求是否有效，防止CSRF攻擊。這個方案，會在授權時把state參數先存到cookie裡面，所以這個參數用來指定這個state參數存入的cookie名稱，默認值是wx_state_cookie
state_cookie_time：指定wx_state_cookie的有效時長，默認是5分鍾
這七個參數有2種設置方式。
第一種是把這些參數以大寫的形式配置到.env配置文件裡面：
image
註：1、每個配置項都是大寫，且以WEIXIN_開頭；2、前三個配置項與前面介紹的參數名稱不完全一致，KEY對應client_id，SECRET對應client_secret，REDIRECT_URI對應redirect；3、其它的與前面介紹的參數名稱一致。
第二種是把這些參數配置到config/services.php文件裡面去：
image
這種方式的配置，每個配置項的名稱與前面介紹的一致。
要注意的內容：
由於php_weixin_provider是基於laravel/socialite實現的，它要求必須配置client_id，client_secret和redirect，否則php_weixin_provider實例化過程就會出錯；對於client_id和client_secret，我認為統一配置在一個地方是沒有問題的，但是對於redirect，如果統一配置，不一定符合所有場景的需求，因為不是每一個用到微信登錄的地方，最後的回調地址都是同一個；所以建議把redirect先配置成一個有效或無效非空的回調地址；反正在後面使用php_weixin_provider的時候還可以在調用的時候更改這個參數的值。
proxy_url如果有，也建議配置在公共的地方；
state_cookie_name和state_cookie_time由於都有默認值，基本上無需重新配置；
device可以在使用的時候再指定。
所有配置參數都可以在使用的時候重新指定。
3. 注冊php_weixin_provider
在項目的config/app.php文件裡面，找到providers配置節，把如下代碼加到它的配置數組裡面：
image
4. 注冊第三方登錄事件的監聽
在項目的app/Providers/EventServiceProvider.php裡面加入以下代碼：
image
laravel框架整體上是一種IOC跟事件驅動的思想，熟悉js就會對事件驅動非常熟悉，熟悉設計模式，就會對IOC（控制反轉，也稱為DI：依賴注入）比較熟悉，這個是理解第3步和第4步配置作用的關鍵。
5. 編寫微信登錄的介面
舉例如下：
+ View code
Socialite::with('weixin')會返回php_weixin_provider的實例，也就是它：
image
拿到這個實例之後，就可以採用鏈式的方式調用它提供的所有public方法，比如設置配置參數，setDevice等等。
6. 編寫微信登錄回調的介面
舉例如下：
+ View code
通過Socialite::with('weixin')拿到php_weixin_provider實例後，調用user方法，就會自動跟微信調用相關介面，並把微信的返回值封裝成對象返回。如果在此過程中，有任何錯誤都會以異常的形式拋出，比如state參數校驗失敗，比如code失效等。
返回的$user對象包含的有效屬性有：
image
小結：
這個方案是基於laravel/socialite實現，並發布到composer來使用的。laravel/socialite是laravel官方提供的第三方登錄的模塊，基於它可以很方便的集成大部分第三方平台的認證，目前它官方已經提供很多第三方的登錄實現：https://socialiteproviders.github.io/。除了國外的facebook,google,github等，國內的微信，微博，qq也都有提供。我在一開始也用的是它官方提供的默認的微信登錄provider來做的，但是後來我發現了以下幾個問題：
1. 不支持微信授權的代理；
2. pc端跟移動端竟然還是分兩個項目來做的:
image
3. 它封裝的user對象里竟然不包含unionid
4. 更改配置參數的方式，實在是讓人覺得難以使用：
image
所以我就在它官方的微信登錄provider基礎上，按照自己的想法，重新實現了一個來解決我發現的這些問題