Durch meine ersten Gehversuche mit Grails sowie einen interessanten Vortrag über JSF2 bin ich kürzlich über das Kürzel “IoC” gestoßen. Das ganze ist vom Prinzip her recht einfach und in Grails, das im Grunde ein stinknormales MVC-Pattern implementiert, konkret gelöst, indem man durch eine Namenskonvention am Controller automatisch sogenannte Services instanziiert.
Also anstatt zu schreiben:
class DefaultController {
def mySuperService
def index = {
mySuperService = new MySuperService(params);
mySuperService.getData()
}
}
schreibe ich einfach
class DefaultController {
def mySuperService
def index = {
mySuperService.getData()
}
}
Gut, sieht jetzt nicht besonders spektakulär aus, doch wenn man weiß, dass mySuperService im Hintergrund (Stichwort “Spring Managed Bean”) automatisch instanziiert sowie an meinen Controller gebunden wurde und dass da prinzipiell noch viel mehr geht, ist das bereits ein ganz brauchbares Feature.
Natürlich ist die Injizierung per Naming-convention eine Grails-eigene Lösung (alles, was auf Service endet, ist ein Service und wird injiziert), um Konfigurationsarbeit zu sparen. Für gewöhnlich wird das Verhalten sogenanner “managed Beans” natürlich konfiguriert, entweder Java-typisch via XML-Konfigurationsdatei oder durch Annotationen.
Dabei kann wiederum java-typisch auch der “Scope” einer Bean bestimmt werden; hier bringt vor allem der “Singleton” bzw. Application Scope einen Vorteil gegenüber einer statuslosen PHP-Anwendung. Doch bereits die Fähigkeit, den Scope überhaupt fein granulieren zu können, setzt das ganze wieder von PHP-Gemurkse ala $_SESSION, $_REQUEST etc. ab.
Also egal wo und in welchem Kontext man Managed Beans, Enterprise Java Beans, Spring Beans (Die Unterschiede interessieren hier mal nicht die Bohne – ich könnte sie auch gar nicht qualifiziert erläutern) einsetzt – das IoC-Muster spart Code, vereinfacht Abhängigkeiten und sorgt für schlankere Konstruktoren – ist insgesamt also eine sehr mächtige Sache.
Was aber nicht heißt, dass so etwas generell nicht auch in meiner PHP-Anwendung funktionieren kann.
sfDependencyInjectionContainerPlugin
Dieses Plugin (http://www.symfony-project.org/plugins/sfDependencyInjectionContainerPlugin) leistet genau das: Es verwaltet entweder über eine in PHP formulierte DSL(hust), über XML oder eine symfony-typische .yml-Datei konfigurierte Abhängigkeiten. Das Plugin ist selbst nur ein Adapter, das die Symfony-Komponente DependencyInjection in ein Symfony 1.2 (und höher) Projekt integriert – in Symfony 2.0 wird DependencyInjection voraussichtlich Bestandteil des Systemkerns sein.
Zur Installation und Konfiguration des Plugins verweise ich auf die README-Datei. Trotzdem vielleicht der Hinweis, dass die Bibliotheken mit einem eigenen Autoloader daherkommen, daher empfehle ich, folgende Programm-Zeilen in eure ProjectConfiguration.class.php hinzuzufügen:
config/projectConfiguration.class.php
require_once dirname(__FILE__) . '/../pfad/zur/DependencyInjection/Komponente/sfServiceContainerAutoloader.php'; sfServiceContainerAutoloader::register();
Anders habe ich es nicht hinbekommen, zwar lässt sich durch eine config/autoload.yml die Laufzeit von Class Not Found-Fehlern befreien, aber das Symfony Command Line Interface geht dann trotzdem hops. Für einen Tipp, wie man’s eleganter hinkriegt, wäre ich dankbar.
Beispielsweise möchte ich den Nerdpress-RSS-Feed in meine Seite einbinden. Dazu baue ich einen Proxy, um bequem via AJAX auf das entfernte RSS-XML zugreifen zu können.
Diesen Proxy definiere ich als Service und injiziere ihn meine Symfony-Module:
config/services.yml:
services:
NerdpressRssProxy:
class: NerdpressRssProxy
Diese drei Zeilen reichen bereits aus, um meine Abhängigkeit zu definieren.
Nun implementiere ich die Service-Klasse:
lib/NerdpressRssProxy.php
class NerdpressRssProxy
{
/**
* @var sfFileCache
*/
protected $cache;
/**
* @return sfFileCache
*/
public function getCache()
{
if (null === $this->cache)
{
$this->cache = new sfFileCache(array('cache_dir' => sfConfig::get('sf_cache_dir')));
}
return $this->cache;
}
/**
* @return string
* @throws Exception
*/
public function getEntries()
{
$cache = $this->getCache();
sfContext::getInstance()->getConfiguration()->loadHelpers(array('Helper', 'Tag', 'Url', 'Text'));
if(!($rss = $cache->get('nerdpress_rss')))
{
if(($rss = @file_get_contents('https://nerdpress.org/feed')))
{
$rss = auto_link_text($rss, 'all', array('class' => 'external'));
$cache->set('nerdpress_rss', $rss, 3600);
}
else
{
throw new Exception('Rss feed could not be opened');
}
}
return $rss;
}
}
Die Methode getEntries() rufe ich nun in meinem Nerdpress-RSS-Modul auf, um die WebResponse zu befüllen:
apps/frontend/modules/rssProxy/actions/actions.class.php
class rssProxyActions extends sfActions
{
public function preExecute()
{
$this->getResponse()->setContentType('application/rss+xml');
}
public function executeNerdpress(sfWebRequest $request)
{
try
{
// SERVICE HOLEN UND getEntries() AUFRUFEN
$rss = $this->getService('NerdpressRssProxy')->getEntries();
$this->getResponse()->setHttpHeader('Content-Length', mb_strlen($rss));
$this->getResponse()->setContent($rss);
}
catch(Exception $e)
{
$this->forward404($e->getMessage());
}
return sfView::NONE;
}
}
Das wars. Einfach, oder? Ingesamt 3 Zeilen yml-Konfiguration reichen, um Dependency Injection “the PHP way” zu realisieren, Symfony sei Dank. Natürlich ist nicht *ganz* so hübsch wie in der J2EE-Welt und sicherlich funktional noch weit davon entfernt. Aber ein Anfang ist gemacht, und wenn man seine Services erst einmal auf diese Art und Weise unter Kontrolle bringt, ist man vom Nutzen der Sache schnell überzeugt: Mit ein bisschen Disziplin gehören “Controller-Spaghettiwürste” nämlich der Vergangenheit an.
Bitte entschuldigt eventuell fehlerhafte oder unsaubere Beschreibungen der Begriffe “Bean”, “IoC”, JSF2 etc. Ich bitte explizit um Korrektur in Form von Kommentaren :)