4

I am trying to tidy up an application, and have manually been doing Constructor Dependency Injection for a while.

This is a bit tedious, and I would like to start utilizing a Dependency Injection Container instead.

I am looking for an actively developed and maintained DI container. I have found Crafty as an alternative, which can wire together dependencies with XML, YAML, Arrays or programatically.

The DI container should not be tightly coupled with a full blown framework, we are looking for something simple and pluggable, with the least hassle possible.

Does anyone have a recommendation and why you chose the particular implementation? Thanks for reading.

mattis
  • 73
  • 5
  • 4
    Posting this as a comment since i do not have experience of it, but i know of Symfony Dependency Injection library. It should be decoupled from the rest of the framework and it seems to be pretty flexible. Check it out here http://components.symfony-project.org/dependency-injection/ – alexn Dec 20 '10 at 09:23
  • @alexn - +1, I use the Symfony library and I'm a big fan; we were upgrading an old project with a large number of globals/singletons and switched over to the Symfony library instead in an attempt to clean things up and it's been a great help. – El Yobo Dec 20 '10 at 11:43

3 Answers3

5

Since people seem to like my comment, I post it as an answer. I do not have experience of it, but i know of Symfony Dependency Injection library. It should be decoupled from the rest of the framework and it seems to be pretty flexible. Check it out at Symfony Components.

I also think Substrate looks pretty good. According to the author, it also has production experience, which is always good.

alexn
  • 57,867
  • 14
  • 111
  • 145
1

Bucket seems to fit well with your requirements.

user187291
  • 53,363
  • 19
  • 95
  • 127
0

You can also check out PHP-DI, it features dependency injection through annotations (@Inject) and minimal configuration.

It's very easy to use, and it integrates with Zend Framework very well (if ever you are using it).

(disclaimer: I do work on this framework)

Matthieu Napoli
  • 48,448
  • 45
  • 173
  • 261
  • Using Annotations for configuring a Dependency Injection Container is the most ridiculous thing ever. The DIC exists to separate dependency resolution rules from the application code. The annotations then put this responsibility back in the application code. See http://r.je/php-annotations-are-an-abomination.html for more info (n.b I wrote this article) – Tom B Mar 15 '13 at 17:03
  • "dependency resolution rules" are NOT in the application code, they are in the configuration. Let me repeat: annotations do NOT configure DI. They simply mark a property/setter to be injected, but the choice of the dependency falls back to the DIC config. And I'm working on V3.0 of PHP-DI that make annotations optional btw. Look at Spring's annotations for another example http://blogs.sourceallies.com/2011/08/spring-injection-with-resource-and-autowired/ – Matthieu Napoli Mar 16 '13 at 00:27
  • And annotations are just a metadata source, an alternative to XML or YAML files, just like for Doctrine's ORM mapping. – Matthieu Napoli Mar 16 '13 at 00:30
  • But they are class specific. They are essentially hardcoded. The Spring example is perfect: @Resource(name="person"). This forces the dependency to use the instance named "person" and this dependency is class specific. Your own PHP-DI suffers from this. The example called "Foo" which uses DbAdapter: There is no way to create two instances of "Foo" which use different instances of DbAdapter. Essentially everything is the equivalent of being static a static property shared across every instance of the class. – Tom B Mar 16 '13 at 15:16
  • @TomB you are very right on this case, but you are picking on a specific functionality that is not meant to be abused (just like global vars). It's not the main/standard way to use those frameworks, as well for PHP-DI or Spring. Just like PHP has global variables, that doesn't make PHP bad per say. – Matthieu Napoli Mar 16 '13 at 15:29
  • Of course, but there is zero benefit gained in using annotations beyond mild convenience for the developer, and many many downsides which cause real world problems with flexibility, version control, breaking OOP theory and several others. Annotations are simply not a good idea for storing application specific metadata, full stop. – Tom B Mar 16 '13 at 15:32
  • @TomB I understand your opinion, though I disagree (I won't expend here). Anyway many people share your opinion and that's the reason I started working of V3.0 that don't rely on annotations: https://github.com/mnapoli/PHP-DI/tree/3.0. Thanks for sharing your thoughts though, interesting discussion. – Matthieu Napoli Mar 16 '13 at 15:38