di 依赖注入实现的意义是什么？

一般的 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框架）：

1. 通过配置改变依赖接口的实现，这也是DI功能最基本和最核心的功能

2. 灵活控制依赖实现的实例范围，单例、每个线程一个、每个请求一个等等

3. 依赖的参数，依赖的依赖等管理

4. 代码更加简洁、逻辑更加清楚

5. Mock方便测试方便，这个有了1就好办

总的来说就是把应用中的功能块与功能块之间，类与类之间的依赖关系通过一个统一的框架集中管理起来。

没错，就是解耦。
用个MVC就是解耦完成了？
这是最低层次的解耦好吗？

DI的前提是你需要一个统一的容器去承载你的bean，拥有这么一个容器的时候，你可以对里面的bean进行一些特殊的操作而且不用大篇幅的修改代码，难道这还不够吗？

解耦、方便unit test，显式注入的比较方便管理、最蛋疼的是隐式注入、半天找不到源文件。 laravel的DI其实也就是Requests和services了。