Dependency Container für Contao

Ein Dependency Container ist Teil des Dependency Injection Konzepts. Deshalb bezeichnet man ihn auch als Dependency Injection Container oder kurz DI Container. Die Erweiterung heißt deshalb nur "Dependency Container", weil diese lediglich einen Container für Abhängigkeiten gemäß dem DI Konzept bereit stellt. DI umfasst neben Komponenten (wie den Container) auch Programmierparadigmen und API Definitionen und muss daher von jedem Entwickler selbst "angewendet" werden.

Was macht der Container?

Der Container ist ein zentraler Speicherort für Parameter und Dienste. Parameter und Dienste haben einen Namen, damit ist der Container prinzipiell nichts anderes als ein Key → Value Storage.

Parameter

Parameter sind vergleichbar mit Konfigurationseinstellungen. Innerhalb von Contao machen diese prinzipiell kaum Sinn, da es dort das $GLOBALS['TL_CONFIG'] Array gibt. Mit Ihnen lassen sich aber Dienste gut konfigurieren.

Dienste (Services)

Dienste sind Objekte die bestimmte Funktionen zur Verfügung stellen und vom Container bei Anforderung instanziiert und zur Verfügung gestellt werden. Ob ein Dienst bei jedem Aufruf neu erzeugt wird oder aber als Singleton innerhalb des Containers verbleibt entscheidet der Container.

Wieso ein DI Container?

In Contao werden für Dienste häufig Singleton Klassen eingesetzt. Singleton Klassen lassen sich allerdings nur schwer modifizieren oder rekonfigurieren.

Technische Umsetzung

Der Dependency Container verwendet die Dependency Injection Component von Symfony2.

Zugriff auf den Container

Der Container steht als globales Objekt zur Verfügung:

$GLOBALS['container']->get('foo.bar');

oder

global $container;
$container->get('foo.bar');

Parameter und Dienste konfigurieren

Ein Dienst wird mit register registriert:

$container->register('myServiceName', 'MyClassName')
    ->addArgument('myConstructorArgument')
    ->addMethodCall('myMethodName', array('myMethodArgument'));

Das Beispiel registriert einen Dienst myServiceName, mit der Klasse MyClassName. Außerdem wird ein Argument mit dem Wert 'myConstructorArgument' hinzugefügt, das beim Instanziieren an den Konstruktor übergeben wird. Anschließend wird noch die Methode myMethodName aufgerufen, mit dem Parameter 'myMethodArgument'.

Umgesetzt im PHP Code entspricht dies:

$myServiceName = new MyClassName('myConstructorArgument');
$myServiceName->myMethodName('myMethodArgument');

Parameter lassen sich einfach mit setParameter definieren:

$container->setParameter('myservice.myproperty', 'myValue');

Parameter können auch komplexe Werte wie Arrays und Objekte beinhalten.

Parameter können mit getParameter wieder abgefragt werden oder mit '%<parameter name>%' innerhalb der Service-Konfiguration wieder verwendet werden.

$container->register('myServiceName', 'MyClassName')
    ->addArgument('%myservice.myproperty%')

Welche Möglichkeiten der Container genau liefert, lässt sich in der Basic usage nachlesen.

services.php, services.yml, services.xml

Konfiguriert wird der Container innerhalb einer services.php, services.yml oder services.xml, die innerhalb des config/ Verzeichnisses im Modul abgelegt werden muss. Die einfachste Möglichkeit ist natürlich über die services.php, wie im oben gezeigtem Beispiel. Wie die Konfiguration mittels services.yml bzw. services.xml funktioniert, kann den Kapiteln Setting Up the Container with Configuration Files und Parameters in Configuration Files entnommen werden.

lokale services.php, services.yml, services.xml

Um die Parameter und Services lokal zu überschreiben kann eine services.php, services.yml oder services.xml in system/config/ hinterlegt werden.

Verwenden von TL_CONFIG Einträgen

Die Einträge aus $GLOBALS['TL_CONFIG'] sind als Parameter mit dem Prefix contao. registriert, z.B. entspricht contao.adminEmail der Variable $GLOBALS['TL_CONFIG']['adminEmail'].