What is the significance of di dependency injection implementation?

General PHP framework, an Application, the life cycle is roughly like this: Request > Router / Url > Dispatch > Controller/Action [ > Service] > Model > [ > View] > Response, Of course there may be some differences, but most of them are just like this.

What is the significance of introducing di injection? Is it to design the objects involved in the application process into components to achieve decoupling? Such as RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter, etc.?

But the general process of an ordinary request with view and database operation is the same for everyone (ROR / J2EE / PHP MVC). Even restful has Router / Request / ControllerAction / Response. What is the meaning of decoupling? After solving it, I still have to take it out and form an MVC process. It's like Router depends on Request, so how about injecting it manually? Router constructor parameter is RequestInterface $request? What kind of Request object does the current application entry decide to inject? Is it possible that Router will one day rely on a strange gadget?

Is it just for the convenience of mocking? Or is it for the uncertain future? Or there are other reasons. . .

Reply content:

General PHP framework, an Application, the life cycle is roughly like this: Request > Router / Url > Dispatch > Controller/Action [ > Service] > Model > [ > View] > Response, Of course there may be some differences, but most of them are just like this.

What is the significance of introducing di injection? Is it to design the objects involved in the application process into components to achieve decoupling? Such as RequestInterface/HttpRequest/CliRequest, RouterInterface/SimpleRouter/RegexRouter/MapRouter, etc.?

But the general process of an ordinary request with view and database operation is the same for everyone (ROR / J2EE / PHP MVC). Even restful has Router / Request / ControllerAction / Response. What is the meaning of decoupling? After solving it, I still have to take it out and form an MVC process. It's like Router depends on Request, so how about injecting it manually? Router constructor parameter is RequestInterface $request? What kind of Request object does the current application entry decide to inject? Is it possible that Router will one day rely on a strange gadget?

Is it just for the convenience of mocking? Or is it for the uncertain future? Or there are other reasons. . .

My view on DI has always been that it is more about dependency management than dependency injection. In fact, it is similar to composer, pip, maven and other higher-level dependency management tools between applications and libraries. The DI framework will bring These benefits (provided it is a good DI framework):

1. Change the implementation of dependent interfaces through configuration, which is also the most basic and core function of DI function

2. Flexibly control the instance scope of dependent implementations, singleton, one per thread, one per request, etc.

3. Dependent parameters, dependent dependencies, etc. management

4. The code is more concise and the logic is clearer

5. Mock is convenient for testing. This is easy to do with 1

In general, it is to centrally manage the dependencies between function blocks and classes in the application through a unified framework.

That’s right, it’s decoupling.
Using MVC is decoupling complete?
This is the lowest level of decoupling, okay?

The premise of DI is that you need a unified container to host your beans. When you have such a container, you can perform some special operations on the beans inside without having to modify the code extensively. Isn't this enough?

Decoupling, convenient for unit testing, explicit injection is easier to manage, but the most painful thing is implicit injection, and the source file cannot be found for a long time. Laravel's DI is actually Requests and services.