UNMAINTAINED
This bundle is no longer maintained. Feel free to fork it if needed., (*1)
ContainerWrapperBundle
Because don't screw DI by just injecting everything., (*2)
This bundle is for people who do not like container injection but are forced to use it.
It provides a configurable proxy container that exposes only parts of the actual container,
or has certain services re-defined. Instead of injecting the full container you can then
inject this wrapper instead, which gives you back fine-grained control over the dependencies
of that component., (*3)
1. It provides an abstract ``liip_container_wrapper.service`` service to extend from.
2. It provides a way to easy set default service and parameters to map
3. It can replace itself with an alias to ``service_container`` via a config
option as long as no service/parameter is mapped to a different id/name
Installation
1. Install with Composer
`php composer.phar require liip/container-wrapper-bundle`
2. Add this bundle to your application's kernel:
// application/ApplicationKernel.php
public function registerBundles()
{
return array(
// ...
new Liip\ContainerWrapperBundle\LiipContainerWrapperBundle(),
// ...
);
}
Configuration
Default services and parameters maybe configured inside the application configuration.
Setting disable_optimization to true will remove the ContainerWrapper service in favor of an
alias to service_container in all cases where no mapping is used:, (*4)
# app/config.yml
liip_container_wrapper:
services:
templating: acme_hello.templating
parameters:
kernel.debug: true
disable_optimization: %kernel.debug%
Both services and parameters are configured as key value pairs. The key is the id/name
that is reachable from this specific ContainerWrapper instance. The value may either be
true or an id/name of a different service or parameter. In case of a non true value
the id/name will be mapped to this other id/name., (*5)
Take the above example:, (*6)
// will return an instance of the 'acme_hello.templating' service
$container->get('templating');
// will return an the value of the 'kernel.debug' parameter
$container->getParameter('kernel.debug');
Note that because templating is mapped to a different service id, setting
disable_optimization to false would have no effect, since a normal
Container instance would not be able to support setting different alias's
for templating., (*7)
Example use
The following YAML configuration extends the liip_container_wrapper.service abstract
service to define an acme_hello.container service that can be injected in place of
a Container instance that limits access to the services and parameters defined
in the bundle configuration as well as the ones defined in this configuration:, (*8)
acme_hello.foo.controller:
class: Acme\HelloBundle\Controller\FooController
calls:
- ['setContainer', [ @acme_hello.container ] ]
acme_hello.container:
parent: liip_container_wrapper.service
arguments:
index_0:
some_service: true
The story of saved kittens
Why oh why?
Yes, why oh why would someone bother to setup a nice dependency injection container
and then waste all its goodness by just injecting the entire container, thereby
effectively making their code dependent on essentially everything configured in the
DI container? I am sure god kills more than a few kittens whenever .., (*9)
Aside from the kittens, injecting the container also prevents granular adjustments
to your dependencies. Aka controller Blabla needs a different templating service
injected than controller DingDing, but how do you do that if your code uses
$this->container->get('templating') in both? Praying to god is not the answer,
he is busy killing kittens anyway., (*10)
And those insane enough to bother with unit testing will also quickly realize that
its even less fun to have to wrap everything they want to inject into a container
mock object., (*11)
Oh and no IDE auto completion support without jumping through hoops is also a major
let down of injecting the container or is there an IDE yet that can parse your DIC
to figure out wtf $this->container->get('i_hate_kittens') returns?, (*12)
But ok, there are many crappy answers like lazyness and such to still inject the DIC,
but there are three semi acceptable reasons:, (*13)
1) someone else wrote useful code, but thought it was a great idea to require injecting
the entire DIC, (*14)
2) there are a fair bit of optional dependencies which do not really solve themselves
by splitting up the service (actually 2) is often a reason why 1) happens even for
code written by good people)., (*15)
3) you need to inject a service before the service actually can exist, like the
request service in Symfony2, (*16)
But wait there is hope!
In those cases you now have a way to prevent little kittens from being slain!, (*17)
Instead you can use the ContainerWrapper to explicitly configure your dependencies
again and to map hardcoded service id's to regain the flexibility that was forsaking
by not injecting the dependencies explicitly., (*18)
But parameters!
Yeah, parameters are also handled by the wrapper, though they don't really benefit
from the lazy loading argument all that much, but I guess once a developer has gone
the path of darkness, he might just keep using the DI container instead of explicitly
injecting the parameters, so yeah, probably parameter support should be added too. Evil
is just so resourceful at being evil., (*19)
Wallogit.com
