### :-: **iThink里的依賴注入實現**
**在序言中筆者曾提及iThink擁有一套自定義的依賴注入機制,利用這套機制,可以使我們在開發的過程中十分方便的拿到各種層級的實例,只要可以通過model函數調用得到的對象,都可以通過調用一個屬性得到,這里我們深入解讀一下這套機制的實現原理。**
> 
> 
觀察打印出來的結果,2411 行和 2422 行用兩個不同的方式都得到了 app\common\logic\Config 這個對象,用全等比較,返回的是 treu。使用的 model函數方式實例化模型大家一定很熟悉,那么上面的 $this->logic__common_Config 是怎么得到這個模型的?
這里需要兩個知識點,一個是__get 方法的原理,一個是trait的使用
在一個類中調用他不存在的屬性時,他會自動調用 __get 方法,將調用的屬性做參數傳入,由我們自行編寫處理的邏輯,利用這個機制,我們就可以實現一套依賴注入的機制了
我們請求這個方法

將請求斷點設置在2411行,當我在斷點處讓代碼繼續執行時,由于前面沒有定義這個 logic__common_Config 屬性,毫無疑問代碼會走到 __get 方法里去,因此,我們在基類里定義了 __get 方法,跟進

logic__common_Config 會作為參數傳入,在 127 行用正則對其進行了解析,解析后的結果為上圖的 $result 變量,然后我們對這幾個參數進行了重組,在 144 行和 148行進行了計算,得到 $layerName 和 $modelName 兩個參數,直接吧這兩個參數傳入到 model 方法即可得到我們需要的實例,和手動調用 model 得到的結果意義,只不過這個過程被 __get 替我們做了,至此,我們在控制器里就可以直接使用這種方法實例化模型了
其實這個__get方法就是寫在 trait 里,而控制器,模型,驗證器,等基類都引入了這個 trait,所有在他們里面都可以實現這個機制了
- 序言
- 圖片預覽
- 詮釋高效開發
- 提問的智慧
- GIT命令參考
- 安裝composer
- 斷點調試技巧
- 調試環境的搭建
- 調試工具的使用及技巧
- 前置基礎-TP底層講解
- 理解編程的抽象
- 耦合與解耦
- 自動加載
- 反射類
- 控制反轉(IOC)和依賴注入(DI)
- iThink 自定義依賴注入的實現
- 常用設計模式
- SPL標準庫
- 行為-鉤子-插件
- AOP-面向切面
- RBAC和Auth類的本質
- 安裝iThink
- 環境要求
- 代碼下載與環境配置
- 執行安裝
- 體驗測試模塊
- apache配置
- nginx配置
- 系統架構詳解
- 目錄詳解
- 執行流程圖
- 數據字典
- RBAC 權限管理架構
- 系統分層詳解
- 控制器層(controller)
- 邏輯層(logic)
- 視圖層(view)
- 模型層(model)
- 服務層(service)
- 應用包架構詳解
- 目錄結構
- 開發規范
- 數據庫規范
- 編碼規范
- 功能設計原則與規范
- 后臺功能詳解
- 基礎功能
- RBAC + Auth 權限機制
- 應用化功能機制
- 代碼生成器(重要)
- 應用骨架代碼生成
- 數據表 CURD 代碼生成
- 頁面構造器(重要)
- 通用元素構造器
- 表格元素構造器
- 搜索表單元素構造器
- 表單元素構造
- 閉包事物構造器
- 應用的開發
- 函數參考