What parts of the PHP website are handled by the dependency injection container?

Question

After reading a trillion foggy dependency injection container guides, I feel like I still don't fully understand.

When it comes to things specific to the application (e.g. models, controllers, etc.), how do I manage automatic dependency injection?

I may have a BIG website, maybe 30-40 different types of models ... am I really creating one application dependency manager to handle each of these different types?

I had people who told me that DICs are not intended for the contents of the domain, but more for the framework, and I also heard the opposite.

What is the "right"?

BONUS QUESTION:

If DICs are not applicable for domain objects (for example, models), how do you pass dependencies to domain level objects?

Answer 1

It may not be exactly what you are looking for, but here is an example of using Dependency Injection Container (DIC)

Say I have a Database class and a Cache class . I need to have access to my database and Cache class inside my other classes (models, controllers, etc.).

This is a situation where the DIC comes in handy, I can just save my database class and cache inside the DIC class and pass this DIC class to any other class that needs access to the objects it holds

Answer 2

It is not clear what the question is, but I will try.

When it comes to application-specific things (e.g. models, controllers, etc.), how should I manage automatic dependency injection?

Do you use DIC? Are you writing one or using a library?

Perhaps the library will help, I am the author of PHP-DI , so I am biased, but the library helps me automatically enter dependencies.

For example, I can write:

 class UserController { private $formFactory; public function __construct(FormFactory $formFactory) { $this->formFactory = $formFactory; } public function createForm($type, $data, $options) { // $this->formFactory->... } } 

In this situation, the DIC can determine what dependencies your controller requires and auto-inject them. It makes life easier.

I may have a BIG website, maybe 30-40 different types of models ... am I really creating one application dependency manager to handle each of these different types?

Why do you need this? I don’t understand the need, maybe you need to explain a little more what the problem is.

I had people who told me that DICs are not for the domain, but more for the framework, and I also heard the opposite.

What is the "right"?

IMO there is no difference between "domain material" and "framework". The only thing that is difficult is that the DIC introduces the material into the entity, because it is not a “singleton” (not in the Singleton Pattern): these objects are not controlled by the DIC, you can create instances manually everywhere in your code. Example:

 $user = new User(); 

If the User class needs a service, then everywhere in your code you need to do:

 $user = new User($service); 

On the contrary, you never need to create a service manually (you never need to call "new"), so you can let the container instantiate and enter everything.

---

I am not very happy with my answer, as it is a bit vague, but it is difficult for me to determine what the problem is. Maybe you should give some code examples, or at least explain a little more.

PS: I struggled to understand DI and what is DIC too, don’t settle for “I think I get it a little more, though not completely,” I did the same, and it took me months to finally understand.

If this helps, read the introductory text http://mnapoli.imtqy.com/PHP-DI/ and possibly also: http://mnapoli.fr/controllers-as-services/ (not directly related, but may help)