[RFC|Merged] Dependency Injection Container

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
igorw
Registered User
Posts: 500
Joined: Thu Jan 04, 2007 11:47 pm

[RFC|Merged] Dependency Injection Container

Post by igorw »

Since we started using Dependency Injection we have lots of decoupled classes that can be unit tested. That's great. However, assembling these classes is a pain, as you can see by looking at common.php. There's a lot of boilerplate needed. Worse, this is duplicated across common.php, download/file.php, the installer.

We could solve that by using a Dependency Injection Container, or DIC (worst acronym ever). The DIC knows about all services, and how to create them. Whenever you request a service, it will create it on the fly, including any service that it depends on.

Configuration of these services takes place in a static YAML file (could also be XML, TXT, INI or plain PHP).

The Symfony2 DependencyInjection component provides such a container that is pretty much standalone. By adding the YAML and Config components (optional dependencies of DependencyInjection) we can make it even easier to use.

Tying that into phpBB should be quite easy, and allow us to reduce boilerplate.

Reference
See also

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Dependency Injection Container

Post by MichaelC »

+1
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
imkingdavid
Registered User
Posts: 1050
Joined: Thu Jul 30, 2009 12:06 pm

Re: [RFC] Dependency Injection Container

Post by imkingdavid »

So to make sure I understand, you give the DIC all of the objects/variables that you would normally need to give a class when instantiating it, and you give it the class signature so it knows what each class needs, and then when instantiating an object, you just call the DIC and give it the class name, and it passes the appropriate variables into a new object and returns that instance?

That sounds like a good idea, as it will keep the code a bit cleaner. I'm for it.
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Dependency Injection Container

Post by MichaelC »

imkingdavid wrote:So to make sure I understand, you give the DIC all of the objects/variables that you would normally need to give a class when instantiating it, and you give it the class signature so it knows what each class needs, and then when instantiating an object, you just call the DIC and give it the class name, and it passes the appropriate variables into a new object and returns that instance?

That sounds like a good idea, as it will keep the code a bit cleaner. I'm for it.
Only services (global classes like dbal, cache, user, extension manager etc.).
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

igorw
Registered User
Posts: 500
Joined: Thu Jan 04, 2007 11:47 pm

Re: [RFC] Dependency Injection Container

Post by igorw »

Correct.

A service definition contains the information the container needs to create that object. This includes class name and arguments. The arguments can reference other services and parameters. The container can construct any part of the object graph on demand.

Another important part are tags. You can tag services, and then get all services of a specific tag. This allows us to have a `cron.task` tag for all cron tasks. Extensions can add their own cron tasks by defining them as services and tagging them. The cron system just reads all the tasks from the container and checks which ones need to be run. And not only cron tasks can work this way, it works for everything. Potentially we can use it for cache drivers, xcp modules, search drivers, etc.

What is the point? The point is that we don't use globals anymore. This allows the classes to be tested in isolation (unit testing), which makes them more robust. Thus the whole system will be easier to change, and harder to break.

User avatar
brunoais
Registered User
Posts: 964
Joined: Fri Dec 18, 2009 3:55 pm

Re: [RFC] Dependency Injection Container

Post by brunoais »

I like the main idea behind this!
Please give us more info about your idea... I've read your post and it seems it has the idea but not the complete idea.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Dependency Injection Container

Post by MichaelC »

brunoais wrote:I like the main idea behind this!
Please give us more info about your idea... I've read your post and it seems it has the idea but not the complete idea.
Take a look at the PR and symfony links provided as they explain it in more detail.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
Fyorl
Google Summer of Code Student
Posts: 27
Joined: Mon Apr 02, 2012 4:51 am
Location: UK
Contact:

Re: [RFC] Dependency Injection Container

Post by Fyorl »

+1 for the acronym

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: [RFC] Dependency Injection Container

Post by naderman »

Seems like we all agree this is a good move for phpBB code quality and extensibility. Will certainly help with making extensions more comfortable to write.

Senky
Extension Customisations
Extension Customisations
Posts: 315
Joined: Thu Jul 16, 2009 4:41 pm

Re: [RFC] Dependency Injection Container

Post by Senky »

+1 go ahead merging and documenting it! :)

Post Reply