Jusqu'à présent, nous avons parlé de quelques concepts de base. Les exemples des deux premiers articles nous sont très utiles pour comprendre l'implémentation de l'injection de dépendances. Nous allons maintenant approfondir l'implémentation du conteneur de services Symfony 2.
Le conteneur d'injection de dépendances dans Symfony est géré par une classe appelée sfServiceContainer
Le conteneur Symfony peut exister en tant que composant indépendant Le référentiel Subversion officiel de Symfony peut être téléchargé : http://svn .symfony-. project.com/components/dependency_injection/trunk/
. Il convient de noter que ce composant est toujours en développement itératif continu, il peut donc être mis à jour à tout moment (cela a été dit en 2009, mais cela semble s'être arrêté maintenant).
Selon la philosophie de conception de Symfony, tout service peut être un objet géré par un conteneur. Dans l'exemple Zend_Mail présenté dans l'article précédent, il y a deux objets : mailer et 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; } }
Si la classe Container hérite de la classe sfServiceContainer de Symfony, le code peut être un peu plus simple
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; } }
Par observation : Le code de gestion de la configuration du constructeur et des paramètres est omis.
Mais ce n'est pas tout. sfServiceContainer peut nous offrir une interface puissante et concise. Voici quelques points à prendre en compte lors de l'utilisation de l'interface :
1. Service. Habituellement, nous convenons que le nom de la méthode commence par get et se termine par Service. Chaque service possède un logo unique. Le logo est généralement le nom de la méthode sans le suffixe et le suffixe, séparés par des traits de soulignement. Si la méthode getMailTransportService() est définie, le nom du service est mail_transport
2. La méthode est de type protégé, ce qui signifie que vous ne pouvez pas appeler directement la méthode pour obtenir le service. Nous présenterons plus tard comment utiliser les conteneurs pour obtenir des services.
3. Le conteneur est accessible sous forme de tableau pour obtenir les paramètres transmis. Par exemple : $this['mailer.class']
La marque de service doit être unique et ne peut être composée que de lettres, de chiffres, de « _ » et de « . ». '.' peut être utilisé comme espace de noms (comme mail.mailer et mail.transport).
Voyons maintenant comment utiliser ce nouveau conteneur
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;
Comme la classe Container hérite de sfServiceContainer, l'interface devient très soignée.
Le service est accessible via l'interface unifiée
if ($sc->hasService('mailer')) { $mailer = $sc->getService('mailer'); } $sc->setService('mailer', $mailer);
Un moyen plus simple est d'accéder au service via les attributs
if (isset($sc->mailer)) { $mailer = $sc->mailer; } $sc->mailer = $mailer;Les paramètres sont accessibles via l'interface unifiée 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);
Les paramètres sont également accessibles comme des tableaux via des conteneurs
if (!isset($sc['mailer.class'])) { $sc['mailer.class'] = 'Zend_Mail'; } $mailerClass = $sc['mailer.class'];
Les conteneurs peuvent être considérés comme des itérateurs pour parcourir tous les services
foreach ($sc as $id => $service) { echo sprintf("Service %s is an instance of %s.\n", $id, get_class($service)); }
S'il n'y a pas beaucoup de services à gérer, même s'il faut quand même faire beaucoup de travail de base et copier beaucoup de code, il faut admettre qu'utiliser sfServiceContainer est très utile.
Si le nombre de services à gérer augmente de plus en plus, il doit y avoir une meilleure façon de décrire les services.
C'est pourquoi la plupart du temps, nous n'utilisons pas directement la classe sfServiceContainer. Il est néanmoins nécessaire de consacrer un peu de temps à en parler, car il s'agit d'une pierre angulaire importante du conteneur d'injection de dépendances de Symfony.
Ce qui précède est le contenu de la compréhension de la série de conteneurs d'injection de dépendances PHP (3) Symfony Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !