What parts of a PHP website are handled by a Dependency Injection Container?

Question

After reading a trillion vague tutorials on Dependency Injection Containers, I feel as though I'm still not fully getting the point.

When it comes to things that are application specific (like models, controllers, etc), how should I manage the auto-injection of dependencies?

I happen to have a LARGE website, with maybe 30-40 different types of models...do I really create a single application dependency manager to handle each of these different types?

I have had people tell me that DIC's are not meant for domain stuff, but more for framework stuff, and I have also heard the opposite.

Which is "right"?

BONUS QUESTION:

If DIC's aren't applicable for domain layer objects (like models), how do you pass dependencies to the domain layer objects?

By the way, I realize that there is technically not a "right" answer...but some explanation between the philosophies would be much appreciated. — johnnietheblack, Feb 02 '12 at 20:14
Also, I seems like most of the tutorial examples I see are actually for business models...like "ShippingService" etc.....the confusion sets in... — johnnietheblack, Feb 02 '12 at 20:18

score 1 · Answer 1 · answered Sep 16 '13 at 09:34

It's not very clear what the question is, but I'll try.

When it comes to things that are application specific (like models, controllers, etc), how should I manage the auto-injection of dependencies?

Do you use a DIC? Did you write one, or do you use a library?

Maybe a library would help, I am the author of PHP-DI so I'm biased, but the library helps me auto-inject 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 that situation, the DIC can detect what dependencies your controller want, and autoinject them. That makes life easier.

I happen to have a LARGE website, with maybe 30-40 different types of models...do I really create a single application dependency manager to handle each of these different types?

Why would you need that? I don't understand the need, maybe you need to explain a bit more what's the problem.

I have had people tell me that DIC's are not meant for domain stuff, but more for framework stuff, and I have also heard the opposite.

Which is "right"?

IMO there's no difference between "domain stuff" and "framework stuff". The only thing that is hard though, is having a DIC injecting stuff in an entity, because that's not a "singleton" (not in the Singleton Pattern way): these objects are not "managed" 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 have 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 create the instance and inject everything.

I'm not very happy with my answer as it's a bit vague, but I have trouble identifying really what's your problem. Maybe you should give code examples, or at least explain a bit more.

PS: I have struggled to understand DI and what is a DIC too, don't settle for a "I think I get it a bit more now, though not totally", I did the same and it took me months to finally understand.

If it helps, read the introduction text at http://mnapoli.github.io/PHP-DI/ and maybe also: http://mnapoli.fr/controllers-as-services/ (not directly related, but it can help)

score 1 · Accepted Answer · answered Feb 02 '12 at 20:20

1

Maybe not exactly what you are looking for but here is an example usage of Dependency Injection Container (DIC)

Let's say I have a Database class and a Cache class. I need to be able to access my database and my Cache class inside of my other classes (models, controllers, etc).

This is a situation where a DIC would come in handy, I can simply store my Database and Cache class inside the DIC class and pass that DIC class into any other class that needs access to the objects that it holds

answered Feb 02 '12 at 20:20

JasonDavis

48,204
100
318
537

Okay, I am already beginning to see clearer. In this way, though, you are semi-describing your DIC class as a (don't kill me) service locator for framework level services that gets injected into the domain layer objects (vs being some Singleton or global variable). Is that right? – johnnietheblack Feb 02 '12 at 20:27
By the way, if that's so, then I totally get it. Haha, I didn't mean that as a stab on the answer. – johnnietheblack Feb 02 '12 at 20:27
to me a DIC is basically just a container that holds any objects that I need to pass around and access often, instead of pass/injecting multiple objects, I am able to simply pass/inject the DIC object and that object can hold multiple other objects that need to be used throughout an application – JasonDavis Feb 02 '12 at 20:34
1

Interesting. I've also read that passing the DIC into other objects kinda defeats the purpose, because it creates an option for "pulling" your dependencies from it, therefore no longer having them injected. It would seem in that instance that we lose control of the object? – johnnietheblack Feb 02 '12 at 20:40
I'm afraid I don't really follow, a DIC is simply a container, you pass it to where it is needed, if I had 10 objects that I need to access in multiple other objects, instead of manually injecting all 10 objects into X amount of other objects I can simply inject them into my Container and then inject the container to these 10 objects. It kind of sounds like you may have mixed up the DIC with `inversion of control` http://en.wikipedia.org/wiki/Inversion_of_control – JasonDavis Feb 02 '12 at 22:22
I may very well...this whole thing is frustrating...thanks for the clarification on your thoughts tho...i THINK i get it(?) – johnnietheblack Feb 02 '12 at 23:21
I think I got the idea from answers like this (read the accepted answer) http://stackoverflow.com/questions/2539895/dependency-injection-how-to-pass-the-injection-container-around – johnnietheblack Feb 02 '12 at 23:22
Yeah that isn't really a Dependency container, it's really rather simple once you get the concept, I think you possibly over-thinking it and that's why it may seem more complex then it is, I don't really have any good examples to show right now but maybe search SO for other topics on it and maybe it will become more clear. It took me a while to grasp the concept at first and then once I got it, I was like wow its much simpler then I was thinking and over analyzing it, you'll get it – JasonDavis Feb 03 '12 at 22:32
Nope nope nope, sorry I respectfully disagree. You are indeed describing a Service Locator, not a DIC. This is not the same thing, and a Service Locator comes with disadvantages. I'll add an alternative answer to the question. – Matthieu Napoli Sep 16 '13 at 09:21

What parts of a PHP website are handled by a Dependency Injection Container?

2 Answers2