一般的PHP 框架，一個應用Application，生命週期大概是這樣的：Request > Router / Url > Dispatch > Controller/Action [ > Service] > Model > [ > View] > Response，當然可能有些差別，多數無外乎這樣。
那引入 di 注入的意義是什麼？是為了把應用流程涉及的物件設計成元件來實現解耦？例如 RequestInterface / HttpRequest / CliRequest，RouterInterface / SimpleRouter / RegexRouter / MapRouter 等？
但是一個普通的帶視圖帶資料庫操作的請求大致流程大家都一樣啊（ROR / J2EE / PHP MVC），即使是 restful 也是有 Router / Request / ControllerAction / Response 的，這解耦的意義是什麼？解來解去，還得撈出來組個 MVC 流程。就好像 Router 妥妥的依賴 Request，那就手工注入嘍？ Router 建構函式參數是 RequestInterface $request 嘍？目前應用程式入口決定注入何種 Request 物件嘍？難不成哪天 Router 還依賴個奇怪的玩意不成？
難道說只是為了 mock 方便？還是說為了不確定的將來？還是說有其它的原因。 。 。
一般的PHP 框架，一個應用Application，生命週期大概是這樣的：Request > Router / Url > Dispatch > Controller/Action [ > Service] > Model > [ > View] > Response，當然可能有些差別，多數無外乎這樣。
那引入 di 注入的意義是什麼？是為了把應用流程涉及的物件設計成元件來實現解耦？例如 RequestInterface / HttpRequest / CliRequest，RouterInterface / SimpleRouter / RegexRouter / MapRouter 等？
但是一個普通的帶視圖帶資料庫操作的請求大致流程大家都一樣啊（ROR / J2EE / PHP MVC），即使是 restful 也是有 Router / Request / ControllerAction / Response 的，這解耦的意義是什麼？解來解去，還得撈出來組個 MVC 流程。就好像 Router 妥妥的依賴 Request，那就手工注入嘍？ Router 建構函式參數是 RequestInterface $request 嘍？目前應用程式入口決定注入何種 Request 物件嘍？難不成哪天 Router 還依賴個奇怪的玩意不成？
難道說只是為了 mock 方便？還是說為了不確定的將來？還是說有其它的原因。 。 。
我對DI的觀點一向是，與其說依賴注入，不如說是依賴管理，其實有些類似於composer、pip、maven這種更高一層管理應用與庫之間的依賴工具，DI框架會帶來這些好處（前提是好的DI框架）：
透過配置改變依賴介面的實現，這也是DI功能最基本且最核心的功能
靈活控制依賴實現的實例範圍，單例、每個執行緒一個、每個請求一個等等
依賴的參數，依賴的依賴等管理
程式碼更簡潔、邏輯更清楚
Mock方便測試方便，這個有了1就好辦
總的來說就是把應用中的功能塊與功能塊之間，類與類之間的依賴關係透過一個統一的框架集中管理起來。
沒錯，就是解耦。
用個MVC就是解耦完成了？
這是最低層次的解耦好嗎？
DI的前提是你需要一個統一的容器去承載你的bean，擁有這麼一個容器的時候，你可以對裡面的bean進行一些特殊的操作而且不用大篇幅的修改代碼，難道這還不夠嗎？
解耦、方便unit test，明確注入的比較方便管理、最蛋痛的是隱式註入、半天找不到原始檔。 laravel的DI其實也就是Requests和services了。
