Dependency Injection – How to Use DI and DI Containers

dependency-injectiondesigndesign-patternsPHP

I am building a small PHP mvc framework (yes, yet another one), mostly for learning purposes, and I am trying to do it the right way, so I'd like to use a DI container, but I am not asking which one to use but rather how to use one.

Without going into too much detail, the mvc is divided into modules which have controllers which render views for actions. This is how a request is processed:

a Main object instantiates a Request object, and a Router, and injects the Request into the Router to figure out which module was called.
then it instantiates the Module object and sends the Request to that
the Module creates a ModuleRouter and sends the Request to figure out the controller and action
it then creates the Controller and the ViewRenderer, and injects the ViewRenderer into the Controller (so that the controller can send data to the view)
the ViewRenderer needs to know which module, controller and action were called to figure out the path to the view scripts, so the Module has to figure out this and inject it to the ViewRenderer
the Module then calls the action method on the controller and calls the render method on the ViewRenderer

For now, I do not have any DI container set up, but what I do have are a bunch of initX() methods that create the required component if it is not already there.
For instance, the Module has the initViewRenderer() method.
These init methods get called right before that component is needed, not before, and if the component was already set it will not initialize it. This allows for the components to be switched, but it does not require manually setting them if they are not there.

Now, I'd like to do this by implementing a DI container, but still keep the manual configuration to a bare minimum, so if the directory structure and naming convention is followed, everything should work, without even touching the config.

If I use the DI container, do I then inject it into everything (the container would inject itself when creating a component), so that other components can use it?
When do I register components with the DI?
Can a component register other components with the DI during run-time?
Do I create a 'common' config and use that?
How do I then figure out on the fly which components I need and how they need to be set up?

If Main uses Router which uses Request,
Main then needs to use the container to get Module (or does the module need to be found and set beforehand? How?)
Module uses Router but needs to figure out the settings for the ViewRenderer and the Controller on the fly, not in advance, so my DI container can't be setting those on the Module before the module figures out the controller and action…

What if the controller needs some other service? Do I inject the container into every controller? If I start doing that, I might just inject it into everything…

Basically I am looking for the best practices when dealing with stuff like this. I know what DI is and what DI containers do, but I am looking for guidance to using them in real life, and not some isolated examples on the net.

Sorry for the lengthy post and many thanks in advance.

EDIT: after reading a bit more, it seems that injection the container itself into objects and making them use the container to find stuff is actually service location, not dependency injection. So my latest idea is to use factories for the stuff that should be dynamically acquired based on something (like getting controllers based on what the router says), and the container would be injected into the factories where it would be used more like a service locator. The non dynamic components would be registered beforehand, and those components would be built by the container and returned fully operational, with all their dependencies filled.

So the flow would look like this:

get Main from the container, Main is injected with Request, Router and ModuleFactory which uses the container to find modules. This is all pre-configured
Main uses ModuleFactory to create the Module, injected with ModuleRouter, Request, ControllerFactory and ViewRenderer.
Module uses ControllerFactory to create a Controller, injected with any service that it depends on, and then the Module calls the action on the controller, and sends the result to the ViewRenderer to render the view.

Am I getting anywhere with this?

Best Answer

As there is no right or wrong in this question, I could give an example about how I like to use Dependency Injection in PHP.

I'm using the Dependency Injection Component from Symfony with the LosoDiAnnotationsBundle and extracted everything from the Bundle to use it as standalone as the Dependency Injection Component. I'm not using the rest of the Symfony Framework.

There are two functions in my system which use the Dependency Injection Container. The main function and the dispatcher. The main function (application entry point) retrieves the configured Dispatcher like this:

$dispatcher = $service_container->get('Dispatcher');
$response = $dispatcher->route( $request );

The service called "Dispatcher" is either defined in the global dependency config or annotated in the class itself like this:

 /*
 * @Service
 */
 class Dispatcher {
    /**
     * @Inject({"@service_container"})
     */
    public function __construct($serviceContainer) {
        $this->serviceContainer  = $serviceContainer;
    }
 }

The Dispatcher needs this service locator because thats how my routing works. If you use some extra mapping between routes and called methods, you could avoid this.

To inject something into other services I use the @inject annotation:

/** @Inject({"@SomeLogic", "@SomeGateway"}) */
public function setDependencies(SomeLogic $someLogic, SomeGateway $someGateway) {
    $this->someLogic = $someLogic;
    $this->someGateway = $someGateway;
}

I like this approach because the configuration of a Service Class is done in the class itself and not in a separate file. Refactoring doesn't involve messing around with lengthy XML or YAML files.

To not harm the performance I run a script everytime I change some annotations and at build time (or in general on every vagrant up). It uses Symfony's ContainerBuilder and PHP Dumper to generate a PHP Lookup file which extends the Base ServiceContainer Class.

The lookup for the example dispatcher would look like this:

protected function getDispatcherService()
{
    return $this->services['dispatcher'] = new \Some\Dispatcher($this);
}

This looks like a lot of work upfront, but it clearly separates concerns later on, especially in bigger projects. Classes do what they are supposed to do and need little to no non-domain-logic code at all.

And I try to keep factories to an absolutely minimum. The DI Container itself is one big factory and repository but it is not manually maintained.

EDIT:

My Routing Function looks like this, request_uri is something like Controller/action/...

    $path = explode( self::ACTION_SEPARATOR, $request_uri );

    if( empty( $path[1] ))
        throw new RoutingException( 'Invalid Action' );

    $method = ucfirst( $path[1] );
    $className = $path[0].'Controller';
    $qualifiedClassName = 'Some\\Namespace\\'.$className;

    if( !class_exists( $qualifiedClassName ))
        throw new RoutingException(sprintf('Invalid controller "%s" for route "%s"', $qualifiedClassName, $route));
    if( !is_callable( array( $qualifiedClassName, $method ) ))
        throw new RoutingException(sprintf('Invalid Action "%s"', $method));


    $controller = $this->serviceContainer->get( $className );
    call_user_func( array( $controller, $method ), $message );

Related Solutions

Is it a good idea to register views and view models as singletons in an IOC container

Well, it depends on what you need. If you'll never ever have two or more views of the same type, then I guess it's ok to register them as singletons.

But then, what if you have a view composed of two other views (and their view models), for instance, if you are comparing some data? You'll can't use the same instance, since you need to populate those with different data.

Also if you have many views, and some type of navigation, where each view gets created when you get to it, then those singleton views would linger on somewhere when you navigate away from them. The container would be keeping a reference, and they would never get collected.

EDIT: With regard to your comment, I think you wouldn't have any issues if you registered the view as a singleton. Having said that, I wouldn't do it. I usually use "singletons" for stateless (or statefull, but where the state can't be changed after it's set when instantiated the first time) objects like repositories, or objects that absolutely have to be single instances during the whole application lifetime. In MVVM that would be some controller which is responsible for managing views (for navigation). I'd leave the views themselves, and their view models as normal objects, even if at first I'll be using just one of them. This is just my preference, though.

PS: I don't have experience with MVVM Light, but using the container as a service locator is generally considered an anti-pattern by many, as you are introducing a dependency to the container. Your views and view models (and domain models) should be as free as possible of the "infrastructure" constructs such as the container. When your code gets to the view model, it should just have all that it needs, and not look for it using the container.

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

Both Game and WorldFactory class would have FileSystem as their dependencies. Below is an example of dependency injected through a constructor (it is also possible to inject them directly into fields):

@Inject
public Game(FileSystem fs) { }

@Inject
public WorldFactory(FileSystem fs) { }

You could then write a provider inside one of your modules that would construct and return a new FileSystem instance:

@Provides
FileSystem provideFileSystem() {
    return ServiceLocator.getService(FileSystem.class);
}

Once you treated other services similarly, you will be able to completely remove your reliance on ServiceLocator, moving the service-creating code directly into providers.

So then you get an odd instance where the constructor of a game entity requires that you pass an instance to the AudioSystem to it which it can play audio through. It just gets very messy with all these objects/services being explicitly passed around.

Not only this is not messy, this is the whole point of dependency injection. The thing is, however, that you should never explicitly pass all those instances manually. Instead, you can have Guice reconstruct the dependency graph from them and construct all necessary, intermediate objects (or obtain them in any other way you specify in your providers). On your side, creating the final object is just a matter of calling Injector.getInstance(Foo.class) -- it's up to Guice to figure out how to satisify the dependencies.

Best Answer

Related Solutions

Is it a good idea to register views and view models as singletons in an IOC container

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

Related Topic