Dependency Container: Unterschied zwischen den Versionen

Aus Contao Community Documentation

(Die Seite wurde neu angelegt: „{{ExtInfo | Dev=Benutzer:tril | DevSite=http://bit3.de | Version=ab 2.11 | ERLink=https://github.com/bit3/contao-dependency-container | TrackerLink=http://dev…“)
 
Zeile 4: Zeile 4:
 
| Version=ab 2.11
 
| Version=ab 2.11
 
| ERLink=https://github.com/bit3/contao-dependency-container
 
| ERLink=https://github.com/bit3/contao-dependency-container
−
| TrackerLink=http://dev.contao-forge.org/projects/avisota/issues
+
| TrackerLink=https://github.com/bit3/contao-dependency-container/issues
 
}}
 
}}
 
[[Kategorie:Extensions]]
 
[[Kategorie:Extensions]]
Zeile 15: Zeile 15:
 
DI umfasst neben Komponenten (wie den Container) auch Programmierparadigmen und API Definitionen und muss daher von jedem Entwickler selbst "angewendet" werden.
 
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?==
+
==How to use==
  
−
Der Container ist ein zentraler Speicherort für Parameter und Dienste.
+
===Zugriff auf Werte im Container===
−
Parameter und Dienste haben einen Namen, damit ist der Container prinzipiell nichts anderes als ein <code>Key &rarr; Value</code> Storage.
+
  
−
===Parameter===
 
−
 
−
Parameter sind vergleichbar mit Konfigurationseinstellungen.
 
−
Innerhalb von Contao machen diese prinzipiell kaum Sinn, da es dort das <code>$GLOBALS['TL_CONFIG']</code> 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 [http://symfony.com/doc/2.1/components/dependency_injection/index.html Dependency Injection Component] von Symfony2.
 
−
 
−
==Zugriff auf den Container==
 
−
 
−
Der Container steht als globales Objekt zur Verfügung:
 
 
<source lang="php">
 
<source lang="php">
−
$GLOBALS['container']->get('foo.bar');
+
$value = $GLOBALS['container']['foo.bar'];
 
</source>
 
</source>
 
oder
 
oder
 
<source lang="php">
 
<source lang="php">
 
global $container;
 
global $container;
−
$container->get('foo.bar');
+
$value = $container['foo.bar'];
 
</source>
 
</source>
  
−
=Parameter und Dienste konfigurieren=
+
===Werte im Container definieren===
  
−
Ein Dienst wird mit <code>register</code> registriert:
+
Services werden in Modulen über die <code>system/modules/X/config/services.php</code>
−
<source lang="php">
+
oder lokal über die <code>system/config/services.php</code> definiert.
−
$container->register('myServiceName', 'MyClassName')
+
−
    ->addArgument('myConstructorArgument')
+
−
    ->addMethodCall('myMethodName', array('myMethodArgument'));
+
−
</source>
+
−
Das Beispiel registriert einen Dienst '''myServiceName''',  mit der Klasse '''MyClassName'''.
+
−
Außerdem wird ein Argument mit dem Wert <code>'myConstructorArgument'</code> hinzugefügt, das beim Instanziieren an den Konstruktor übergeben wird.
+
−
Anschließend wird noch die Methode '''myMethodName''' aufgerufen, mit dem Parameter <code>'myMethodArgument'</code>.
+
  
−
Umgesetzt im PHP Code entspricht dies:
+
====Parameter====
−
<source lang="php">
+
−
$myServiceName = new MyClassName('myConstructorArgument');
+
−
$myServiceName->myMethodName('myMethodArgument');
+
−
</source>
+
  
−
Parameter lassen sich einfach mit <code>setParameter</code> definieren:
 
 
<source lang="php">
 
<source lang="php">
−
$container->setParameter('myservice.myproperty', 'myValue');
+
$container['myServiceParameter'] = 'value';
 
</source>
 
</source>
−
Parameter können auch komplexe Werte wie Arrays und Objekte beinhalten.
 
  
−
Parameter können mit <code>getParameter</code> wieder abgefragt werden oder mit '%<parameter name>%' innerhalb der Service-Konfiguration wieder verwendet werden.
+
====Services====
 +
 
 
<source lang="php">
 
<source lang="php">
−
$container->register('myServiceName', 'MyClassName')
+
$container['myServiceName'] = function($container) {
−
     ->addArgument('%myservice.myproperty%')
+
    $object = new MyClassName($container['myConstructorArgument']);
 +
     $object->myMethodName('myMethodArgument');
 +
    return $object;
 +
};
 
</source>
 
</source>
−
 
−
Welche Möglichkeiten der Container genau liefert, lässt sich in der [http://symfony.com/doc/2.1/components/dependency_injection/introduction.html#basic-usage Basic usage] nachlesen.
 
−
 
−
==services.php, services.yml, services.xml==
 
−
 
−
Konfiguriert wird der Container innerhalb einer <code>services.php</code>, <code>services.yml</code> oder <code>services.xml</code>, die innerhalb des <code>config/</code> Verzeichnisses im Modul abgelegt werden muss. Die einfachste Möglichkeit ist natürlich über die <code>services.php</code>, wie im oben gezeigtem Beispiel. Wie die Konfiguration mittels <code>services.yml</code> bzw. <code>services.xml</code> funktioniert, kann den Kapiteln [http://symfony.com/doc/2.1/components/dependency_injection/introduction.html#setting-up-the-container-with-configuration-files Setting Up the Container with Configuration Files] und [http://symfony.com/doc/2.1/components/dependency_injection/parameters.html#parameters-in-configuration-files Parameters in Configuration Files] entnommen werden.
 
−
 
−
===lokale services.php, services.yml, services.xml===
 
−
 
−
Um die Parameter und Services lokal zu überschreiben kann eine <code>services.php</code>, <code>services.yml</code> oder <code>services.xml</code> in <code>system/config/</code> hinterlegt werden.
 
−
 
−
=Verwenden von TL_CONFIG Einträgen=
 
−
 
−
Die Einträge aus <code>$GLOBALS['TL_CONFIG']</code> sind als Parameter mit dem Prefix <code>contao.</code> registriert, z.B. entspricht <code>contao.adminEmail</code> der Variable <code>$GLOBALS['TL_CONFIG']['adminEmail']</code>.
 

Version vom 16. Mai 2013, 20:36 Uhr

Erweiterungs-Übersicht
Name des Entwicklers Benutzer:tril
Entwickler Webseite http://bit3.de
Kompatibilität mit Contao Version ab 2.11
Link zum Extension Repository https://github.com/bit3/contao-dependency-container
Link zum Tracker https://github.com/bit3/contao-dependency-container/issues

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.

How to use

Zugriff auf Werte im Container

$value = $GLOBALS['container']['foo.bar'];

oder 

global $container;
$value = $container['foo.bar'];

Werte im Container definieren

Services werden in Modulen über die system/modules/X/config/services.php oder lokal über die system/config/services.php definiert.

Parameter

$container['myServiceParameter'] = 'value';

Services

$container['myServiceName'] = function($container) {
    $object = new MyClassName($container['myConstructorArgument']);
    $object->myMethodName('myMethodArgument');
    return $object;
};
Von „https://de.contaowiki.org/index.php?title=Dependency_Container&oldid=7208“
Ansichten
Meine Werkzeuge

Contao Community Documentation

Pelle: gibt's ein besseres Wort für "beschränkt"?
Thomas: "Kunde"

Navigation
Verstehen
Verwenden
Entwickeln
Verschiedenes
Werkzeuge