Understanding PHP Dependency Injection Container Series (3) Symfony

Up to now, we have talked about some basic concepts. The examples in the first two articles are very helpful for us to understand the implementation of dependency injection. Now we will go deep into the implementation of Symfony 2 service container.
The dependency injection container in Symfony is managed by a class called sfServiceContainer

The Symfony container can exist as an independent component. Symfony's official Subversion repository can be downloaded: http://svn .symfony-project.com/components/dependency_injection/trunk/
. It is worth noting that this component is still under continuous iterative development, so it may be updated at any time (it was said in 2009, but it seems to have stopped now).

According to Symfony’s design philosophy, any service can be an object managed by a container. In the Zend_Mail example introduced in the previous article, there are two objects: mailer and mail_transport

class Container
{
  static protected $shared = array();
  protected $parameters = array();
  public function __construct(array $parameters = array())
  {
    $this->parameters = $parameters;
  }
  public function getMailTransport()
  {
    return new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
      'auth'     => 'login',
      'username' => $this->parameters['mailer.username'],
      'password' => $this->parameters['mailer.password'],
      'ssl'      => 'ssl',
      'port'     => 465,
    ));
  }
  public function getMailer()
  {
    if (isset(self::$shared['mailer']))
    {
      return self::$shared['mailer'];
    }
    $class = $this->parameters['mailer.class'];
    $mailer = new $class();
    $mailer->setDefaultTransport($this->getMailTransport());
    return self::$shared['mailer'] = $mailer;
  }
}

If the Container class inherits Symfony's sfServiceContainer class, the code can be made a little simpler

class Container extends sfServiceContainer
{
  static protected $shared = array();
  protected function getMailTransportService()
  {
    return new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
      'auth'     => 'login',
      'username' => $this['mailer.username'],
      'password' => $this['mailer.password'],
      'ssl'      => 'ssl',
      'port'     => 465,
    ));
  }
  protected function getMailerService()
  {
    if (isset(self::$shared['mailer']))
    {
      return self::$shared['mailer'];
    }
    $class = $this['mailer.class'];
    $mailer = new $class();
    $mailer->setDefaultTransport($this->getMailTransportService());
    return self::$shared['mailer'] = $mailer;
  }
}

By observation: The constructor and parameter configuration management code are omitted.
But that’s not all. sfServiceContainer can give us a powerful and concise interface. The following are some points to pay attention to when using the interface:
1. The name of the method to obtain the service must be suffixed with Service. Usually we agree that the name of the method starts with get and ends with Service. Each service has a unique logo. The logo is usually the method name without the prefix and suffix, separated by underscores. If the getMailTransportService() method is defined, the service name is mail_transport
2. The method is of protected type, which means you cannot directly call the method to obtain the service. We will introduce how to use containers to obtain services later.
3. The container can be accessed as an array to obtain the passed parameters. For example: $this[‘mailer.class’]
The service mark must be unique and can only consist of letters, numbers, ‘_’ and ‘.’. '.' can be used as a namespace (such as mail.mailer and mail.transport).

Now let’s see how to use this new container

require_once 'PATH/TO/sf/lib/sfServiceContainerAutoloader.php';
sfServiceContainerAutoloader::register();
$sc = new Container(array(
  'mailer.username' => 'foo',
  'mailer.password' => 'bar',
  'mailer.class'    => 'Zend_Mail',
));
$mailer = $sc->mailer;

Because the Container class inherits sfServiceContainer, the interface becomes very neat.

The service is accessed through the unified interface

if ($sc->hasService('mailer'))
{
  $mailer = $sc->getService('mailer');
}
$sc->setService('mailer', $mailer);

A simpler way is that the service is accessed through attributes

if (isset($sc->mailer))
{
  $mailer = $sc->mailer;
}
$sc->mailer = $mailer;

The parameters are accessed through the unified interface

if (!$sc->hasParameter('mailer_class'))
{
  $sc->setParameter('mailer_class', 'Zend_Mail');
}
echo $sc->getParameter('mailer_class');
// Override all parameters of the container
$sc->setParameters($parameters);
// Adds parameters
$sc->addParameters($parameters);

Parameters can also be accessed through the container like an array

if (!isset($sc['mailer.class']))
{
  $sc['mailer.class'] = 'Zend_Mail';
}
$mailerClass = $sc['mailer.class'];

The container can be viewed as an iterator, traversing all services

foreach ($sc as $id => $service)
{
  echo sprintf("Service %s is an instance of %s.\n", $id, get_class($service));
}

If there are not many services that need to be managed, although you still have to do a lot of basic work and copy a lot of code, you have to admit that using sfServiceContainer is very useful.
If the number of services to be managed becomes more and more, there must be a better way to describe the services.
This is why most of the time, we do not use the sfServiceContainer class directly. Even so, it is necessary to spend some time talking about it, because it is an important cornerstone of Symfony's dependency injection container.

The above is the content of understanding PHP dependency injection container series (3) Symfony. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!