Dependency Injection¶

Dependency Injection is a design pattern where you pass dependencies to services instead of creating them from within the service or relying on globals. This generally leads to code that is decoupled, re-usable, flexible and testable.

Here is an example of a class that takes a User object and stores it as a file in JSON format:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

class JsonUserPersister
{
    private $basePath;

    public function __construct($basePath)
    {
        $this->basePath = $basePath;
    }

    public function persist(User $user)
    {
        $data = $user->getAttributes();
        $json = json_encode($data);
        $filename = $this->basePath.'/'.$user->id.'.json';
        file_put_contents($filename, $json, LOCK_EX);
    }
}

In this simple example the dependency is the basePath property. It is passed to the constructor. This means you can create several independent instances with different base paths. Of course dependencies do not have to be simple strings. More often they are in fact other services.

A service container is responsible for creating and storing services. It can recursively create dependencies of the requested services and inject them. It does so lazily, which means a service is only created when you actually need it.

Pimple¶

Pimple makes strong use of closures and implements the ArrayAccess interface.

We will start off by creating a new instance of Pimple -- and because Silex\Application extends Pimple all of this applies to Silex as well:

$container = new Pimple();

or:

$app = new Silex\Application();

$app['some_parameter'] = 'value';

$app['asset.host'] = 'http://cdn.mysite.com/';

echo $app['some_parameter'];

$app['some_service'] = function () {
    return new Service();
};

$service = $app['some_service'];

$app['some_service'] = $app->share(function () {
    return new Service();
});

$app['some_service'] = function ($app) {
    return new Service($app['some_other_service'], $app['some_service.config']);
};

$app['user.persist_path'] = '/tmp/users';
$app['user.persister'] = $app->share(function ($app) {
    return new JsonUserPersister($app['user.persist_path']);
});

1
2
3
4
5
6
7
8
9

$app['closure_parameter'] = $app->protect(function ($a, $b) {
    return $a + $b;
});

// will not execute the closure
$add = $app['closure_parameter'];

// calling it now
echo $add(2, 3);

Core services¶

Silex defines a range of services.

• request: Contains the current request object, which is an instance of Request. It gives you access to GET, POST parameters and lots more!

  Example usage:

  $id = $app['request']->get('id');
  

  This is only available when a request is being served; you can only access it from within a controller, an application before/after middlewares, or an error handler.

• routes: The RouteCollection that is used internally. You can add, modify, read routes.

• controllers: The Silex\ControllerCollection that is used internally. Check the Internals chapter for more information.

• dispatcher: The EventDispatcher that is used internally. It is the core of the Symfony system and is used quite a bit by Silex.

• resolver: The ControllerResolver that is used internally. It takes care of executing the controller with the right arguments.

• kernel: The HttpKernel that is used internally. The HttpKernel is the heart of Symfony, it takes a Request as input and returns a Response as output.

• request_context: The request context is a simplified representation of the request that is used by the Router and the UrlGenerator.

• exception_handler: The Exception handler is the default handler that is used when you don't register one via the error() method or if your handler does not return a Response. Disable it with unset($app['exception_handler']).

• logger: A LoggerInterface instance. By default, logging is disabled as the value is set to null. To enable logging you can either use the MonologServiceProvider or define your own logger service that conforms to the PSR logger interface.

Core parameters¶

• request.http_port (optional): Allows you to override the default port for non-HTTPS URLs. If the current request is HTTP, it will always use the current port.

  Defaults to 80.

  This parameter can be used by the UrlGeneratorProvider.

• request.https_port (optional): Allows you to override the default port for HTTPS URLs. If the current request is HTTPS, it will always use the current port.

  Defaults to 443.

  This parameter can be used by the UrlGeneratorProvider.

• locale (optional): The locale of the user. When set before any request handling, it defines the default locale (en by default). When a request is being handled, it is automatically set according to the _locale request attribute of the current route.

• debug (optional): Returns whether or not the application is running in debug mode.

  Defaults to false.

• charset (optional): The charset to use for Responses.

  Defaults to UTF-8.