This is surprisingly not intuitive, as you cannot simply pass an array of integers to a prepared statement. Instead, you need to add special binding types to inform Doctrine that this is indeed an array of integers.

It’s very well explained in the documentation under the Parameters Conversion section:
https://www.doctrine-project.org/projects/doctrine-dbal/en/current/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion
But it is rather hard to find and it took me a while.

The trick is to add the array binding types to the the types parameters to the query method. In the case of integers, it is \Doctrine\DBAL\ArrayParameterType::INTEGER.
Now Doctrine knows how to handle the types in the array while binding the values.

Example:

$sql = 'SELECT * FROM items WHERE id IN (?)'; 
$numbersAsStrings = "1,2,3";
$numbers = array_map('intval', explode(',', $numbersAsStrings));
$users = $con->fetchAllAssociative(
  $sql, 
  [$numbers], 
  [ArrayParameterType::INTEGER]
);

If you omit the types, Doctrine will simply try to bind the array as string, which will fail and you get this error:
Array to string conversion

If you try to pass it as a comma-separated string yourself and omit the types like $numbers = implode(',',array_map('intval', explode(',', $numbersAsStrings))); You will get an error because Doctrine expects an array of values for the IN clause and not a string.
Error:
count(): Argument #1 ($value) must be of type Countable|array, string given

I hope this helps someone finding out how to make WHERE IN SQL queries with Doctrine more quickly than me next time.

First you have to add the extension to Postgres, even if you use the Postgis docker image like postgis/postgis:14-3.3-alpine.

So add this SQL statement to the up method of your first migration:
$this->addSql('CREATE EXTENSION IF NOT EXISTS postgis;');

and the DROP statement for the extension to the down method:
$this->addSql('DROP EXTENSION postgis;');

Now, when using Doctrine with Postgres and Postgis extension, migrations still behave a bit odd and try to remove Sequences created by Postgis, because Doctrine migrations does not take Postgis extension’ s built-in Sequences into account.

So you will find this statements in your first migration, which is basically wrong because –of course– we want to keep the topology and tiger Sequences.

	public function up(Schema $schema): void
	{
		// this up() migration is auto-generated, please modify it to your needs
		$this->addSql('DROP SEQUENCE topology.topology_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.county_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.state_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.place_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.cousub_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.edges_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.addrfeat_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.faces_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.featnames_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.addr_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.zcta5_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.tract_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.tabblock_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.bg_gid_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_gaz_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_lex_id_seq CASCADE');
		$this->addSql('DROP SEQUENCE tiger.pagc_rules_id_seq CASCADE');
	}

	public function down(Schema $schema): void
	{
		// this down() migration is auto-generated, please modify it to your needs
		$this->addSql('CREATE SCHEMA topology');
		$this->addSql('CREATE SCHEMA tiger');
		$this->addSql('CREATE SCHEMA tiger_data');
		$this->addSql('CREATE SEQUENCE topology.topology_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.county_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.state_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.place_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.cousub_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.edges_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.addrfeat_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.faces_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.featnames_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.addr_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.zcta5_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.tract_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.tabblock_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.bg_gid_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_gaz_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_lex_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
		$this->addSql('CREATE SEQUENCE tiger.pagc_rules_id_seq INCREMENT BY 1 MINVALUE 1 START 1');
	}

So we have to teach Doctrine to respect these Postgis features.
Therefor extend the PostgreSqlPlatform class, add the Postgis features as exclude condition to the query:

src/DBAL/PostgisPostgreSqlPlatform.php:

<?php

namespace App\DBAL;

use Doctrine\DBAL\Platforms\PostgreSQLPlatform as PostgreSqlPlatformBase;

class PostgisPostgreSqlPlatform extends PostgreSqlPlatformBase
{
	public function getListNamespacesSQL()
	{
		# exclude postgis schemas
		return "SELECT schema_name AS nspname
				FROM   information_schema.schemata
				WHERE  schema_name NOT LIKE 'pg\_%'
				AND schema_name NOT LIKE 'topology'
				AND schema_name NOT LIKE 'tiger%'
				AND    schema_name != 'information_schema'";
	}

	public function getListSequencesSQL($database)
	{
		return 'SELECT sequence_name AS relname,
					   sequence_schema AS schemaname,
					   minimum_value AS min_value, 
					   increment AS increment_by
				FROM   information_schema.sequences
				WHERE  sequence_catalog = ' . $this->quoteStringLiteral($database) . "
				AND    sequence_schema NOT LIKE 'pg\_%' 
				AND sequence_schema NOT LIKE 'topology%'
				AND sequence_schema NOT LIKE 'tiger%'
				AND    sequence_schema != 'information_schema'";
	}
}

As Gist: https://gist.github.com/ivoba/74a143d8074110ef47f93a581bb0c3f6

Now tell doctrine to use this PostgreSqlPlatform class instead.
In symfony you can add this to config/packages/doctrine.yaml:

doctrine:
	dbal:
		url: '%env(resolve:DATABASE_URL)%'
		types:
			geometry: LongitudeOne\Spatial\DBAL\Types\GeometryType
			point: LongitudeOne\Spatial\DBAL\Types\Geometry\PointType
			polygon: LongitudeOne\Spatial\DBAL\Types\Geometry\PolygonType
			linestring: LongitudeOne\Spatial\DBAL\Types\Geometry\LineStringType
		platform_service: App\DBAL\PostgisPostgreSqlPlatform

This is inspired by this Gist, which does the same for other Postgres extensions: https://gist.github.com/dextervip/a2f384050748d6ee3ed7d573425e9d58

Now you can run your migrations diff bin/console do:mi:di and the Postgis sequences will be respected by the Doctrine.

I still did not get the point regarding dependency resolution, so i simply “composed” the composer file by writing down my own requirements (“i want only the hottest, newest stuff!!”, then tracked down the error messages, removing them by explicetly writing down the missing dependencies by using the latest “dev-*” versions. After that i tried to run the project, which actually did not work, but selective downgrade of some of the bundles (framework, security-extra blahblah) finally did the job.

Feel free to use it in your own projects:

{
	"require" : {
              "symfony/symfony" : "v2.0.12",
              "doctrine/common" : "2.1.4",
              "doctrine/orm" : "2.1.6",
              "symfony/finder" : "v2.0.12",

              "symfony/assetic-bundle" : "2.0-dev",
              "twig/extensions" : "dev-master",
              "jms/security-extra-bundle" : "1.1.0",
              "sensio/framework-extra-bundle" : "2.0-dev",
              "sensio/distribution-bundle" : "2.0-dev",
              "sensio/generator-bundle" : "2.0-dev"

 	},
        "autoload" : {
            "psr-0" : {
                "Acme" : "src/",
            }
        }
}

Create a file named “composer.json” in your project’s root directory, then paste the above code into it and save it.

Now run

$ curl -s http://getcomposer.org/installer | php

After that, download all dependencies by typing

$ php composer.phar install

The easiest way to create a full project including AcmeDemoBundle, AppKernel and the whole stuff is to download the symfony 2 standard distribution without vendors and calling the script from there. The only thing to do is to modify the path to autoload.php, which should point to vendor/.composer/autoload.php.

Now you are able to upgrade your project’s dependencies to the newest versions by simply modifying the composer.json file. Have fun!.

I will show this with my Superleansilexplate and will integrate it there as an example.
Since i dont want to integrate MongoDB in Superleansilexplate it will just become an additional gist.

Given you have some smaller amount of data like a counter that needs to be stored or other loose coupled datasets, we simply speak to MongoDB “directly” and store the data via Doctrine MongoDB Abstraction Layer.
Since i presume the Data / Document Structure isnt that complex we dont use Doctrine MongoDB ODM (the Object Document Mapper).
If you want to use it instead, try this Silex Extensions.

So we use this SilexExtensions collection and install it via git:

 cd mysilexproject
 git clone git@github.com:fate/Silex-Extensions.git vendor/silex-extension

Then we install the doctrine mongodb libary manually:

 git clone --recursive https://github.com/doctrine/mongodb vendor/mongodb

The extension collection has some more poviders but you can just ignore them and just focus on the MongoDbExtension.

– i actually dont like extensions collections. i would prefer to clone each extensions individually. thou its not much code overhead, but when it comes to the vendor dependencies it can become quite messy IMHO –

Alright now the code.
Edit src/app.php and register the namespace for the extension:

 $app['autoloader']->registerNamespace('SilexExtension', __DIR__ . '/../vendor/silex-extension/src');

Then register the MongoDbExtension;

 $app->register(new SilexExtension\MongoDbExtension(), array(
 'mongodb.class_path' => __DIR__ . '/../vendor/mongodb/lib',
 'mongodb.connection' => array(
 'server' => 'mongodb://mysecretuser:mysecretpassw@localhost',
 'options' => array(),
 'eventmanager' => function($eventmanager) {
 }
 )
 ));

and finally query your MongoDB collection of choice and display the resultset as json:

$app->get('/data-from-mongodb', function() use($app) {

$coll = $app['mongodb']->selectDatabase('mydb')->selectCollection('mycoll');
 $query = array(
 'query' => 'value'
 );
 $sort = array(
 'count' => -1,
 );
 $r = $coll->find($query)->sort($sort)->toArray();
 $response = new Response();
 $response->headers->set('Content-type', 'application/json');
 $response->setContent(json_encode($r));
 return $response;
 });

Easy

Mein Lieblingsthema ist ja zur Zeit der Dependency Injection Container. Und irgendwie stinkt mir die ganze Container-Konfiguration noch gewaltig. Meine kläglichen Versuche, selbst mal so was ähnliches wie eine brauchbare Autowiring-Implementierung herunterzubrechen, waren natürlich auch bzw. erst recht nicht der große Wurf – was vor allem daran lag, dass ich den Service Container und damit den ganzen Sinn und Zweck des Ganzen einfach mal wegrationalisiert hatte – Loose Coupling sieht natürlich anders aus, das sei den Kritikern zugestanden. Ich verteidige mich mal dadurch, dass ich eigentlich nur mal mit Mixins rumspielen wollte – da hab’ ich wohl die eine oder andere Begrifflichkeit durcheinander geworfen.

Aber um mal zu des Pudels Kern zu kommen: Ist es wirklich so geil, mit kilometerlangen XML-Dateien, ‘ner Menge Initialisierungscode und ohne mit der heißgeliebten Code-Completion in der IDE meiner Wahl ein Paradigma zu kaufen, das im speziellen Anwendungskontext – nicht im Framework-Kontext – eher selten Anwendung findet?

Es ist doch so: PHP bietet zwar mittlerweile eine vernünftige Reflection API, aber wenig (keine) Möglichkeiten, Code zur Compile- oder Runtime effizient zu injizieren (vorbei bspw. an der Sichtbarkeit, was für Property Injection aus meiner Sicht erforderlich wäre). Mit Handständen geht das mittels der Reflection API, noch fieser mit bspw. Runkit.

Somit ist – (natürlich nur aus meiner Sicht, was im Übrigen für den gesamten “Complaint” gilt – dabei wäre ich wirklich froh, berichtigt zu werden) jeder Versuch, die Konfiguration eines wie auch immer gearteten, auf PHP sitzenden, DIC mit Syntactic Sugar anzureichern, vergeblich. Und Syntactic Sugar ist dringend vonnöten, um das Zeug in der Praxis RAD-tauglich zu machen. Nehme ich PHP den RAD-Faktor, was bleibt denn dann noch übrig?

Symfony 2 behilft sich damit, einen DI-Container zu definieren und ihn als PHP-Code wegzucachen. Dieser hat dann Accessoren für alle definierten Services, Constructor-Injection ist durch Referenzierung in den Konfigurationsdateien möglich. Die Doku spricht zusätzlich von Setter- und Property-Injection, dazu konnte ich aber irgendwie keine dokumentierten Beispiele finden. Es gibt aber immerhin die Möglichkeit, Methoden in der Service-Klasse als Pre- oder Post-Initialization Interceptoren auszuführen.

Letztlich tut der Container, was er soll: Abhängigkeiten in beliebige Instanzen zu injizieren. Bei Bedarf auch gegen ein Interface, aber das ist letztlich aufgrund des Sprachentwurfs nur optional (Was impliziert, das man auf Kosten riesiger Flexibilität – die man nicht braucht – schnell mal riskiert, durch einen falsch konfigurierten DI-Container seine Anwendung kaputt zu machen).

Aber der Aufwand steht meiner Meinung nach noch in keinem Verhältnis zum Nutzen. Am Beispiel einer Controller Extension, die als Service definiert wird, möchte ich das mal demonstrieren. Die offizielle Symfony 2-Dokumentation sagt, dass

To keep things simple, Symfony2 by defaults does not require that controllers be defined as services. Furthermore Symfony2 injects the entire service container into your controller.

Das ist immerhin schon einmal eine Information. Das Standardverhalten ist also, dass ich automagisch eine Controllerklasse habe, die den Container kennt (Wie? Magisch? Ich dachte, Symfony 2 hat die Magie zugunsten transparentem Code und ständiger Kontrolle über jeden Aspekt des Core-Frameworks aufgegeben?). Dadurch, dass er ein ContainerAware Interface implementiert, kennt er auch einen Shortcut auf

$this->container->get('serviceid')

, nämlich

$this->get('serviceid');

. Um Bspw. ein Doctrine-Entity zu persistieren, reichen “ein paar codezeilen”:

     $em = $this->get('doctrine.orm.entity_manager');
     $em->???($myEntity);

Wie hieß die Methode da am Entity Manager jetzt nochmal? Das ist das erste Problem: Dadurch, dass alle Services anonym im Service Container herumdümpeln bzw. auf ihre Instanziierung warten, habe ich in meiner IDE keinerlei Code-Completion mehr. Um das wieder zu erreichen, muss ich entweder
– einen Accessor schreiben (getEntityManager()) und diesen mittels PHP-Doc type-hinten (annotieren) oder
– mindestens einen magischen Docblock davorsetzen, der genau *meiner* IDE die Möglichkeit gibt, den Variablentyp zu erraten (aber ggf. proprietär ist, d.h. in anderen IDEs nicht unbedingt funktionieren muss). Für die Netbeans IDE gibt es dafür bspw. das “vdoc“-Feature.

Das ganze setzt natürlich voraus, dass ich *weiß*, welches Interface der Service doctrine.orm.entity_manager implementiert bzw wie die konkrete Klasse (samt Namespace) desselben heißt. Und vorher muss ich auch noch wissen, wie überhaupt der *Servicename* des Entity Managers lautet.

Bin ich also komplett Ahnungslos, rufe ich erstmal ein Terminal auf, tippe sowas wie

$ app/console container:debug --show-private

ein und suche mir anschließend in der kilometerlangen Liste genau die Services zusammen, die ich brauche.

Dafür brauche ich als Framework-Newbie schonmal richtig tiefgehende Kenntnisse darüber, was ein DIC überhaupt ist, tut und zur Konfiguration erfordert.

Um also das, was “früher” ein

new Cart($color, $maxSpeed)->save()

war, zu erreichen, muss ich nun erstmal ganz schön viel Sport treiben (dieses Beispiel nur exemplarisch, es steht außer Frage, dass die Doctrine 2-Architektur wirklich klasse ist. Das Manko aus meiner Sicht ist die Integration in Sf2, nicht der ORM-Layer an sich.)

Möchte ich den Accessor der ContainerAware-Implementierung am Controller vermeiden und die Services “direkt” injizieren, muss ich ihn selbst als Service am DIC registrieren. Wie das funktioniert, würde den Rahmen sprengen, nur so viel: Der Aufwand steht aus meiner Sicht wieder in keinem Verhältnis zum Ergebnis. Allerdings habe ich damit den Vorteil, dass ich bspw. keine abstrakte Controllerklasse mehr zu erweitern habe – der Controller kann ein simples Popo sein. Dass es aber nicht zu simpel sein darf, zeigt bspw., das ich trotz alledem mindestens einen Constructor definieren muss, der eben alle benötigten Services aufnimmt und an Instanzvariablen bindet. Und das können einige sein – fängt an beim Templating, geht übers Formframework, ggf. den Entity-Manager, einen Mailer und was einem sonst noch so einfällt. Dabei wollten wir doch ab jetzt nur noch leichtgewichtige Controller haben?

Meiner Meinung nach liegt die Lösung der Malaise in zwei Alternativen: Man baut so lange Abstracts, die den ganzen Kram als Shortcuts bereitstellen (dann hätten wir bspw. wieder eine komplexe, abstrakte Kontrollerklasse, die mindestens alles kennt, was in Symfony 1 noch dem ApplicationContext gehörte) – womit wir unser Loose Coupling Pardigma wieder in den Schrank zu den übrigen Ideen stellen können, die im Nachgang irgendwie doch nicht funktionierten. Oder legt Autowiring drüber.

Flow 3 baut bspw. an einem DIC + Autowiring, der alle verwalteten Services durch eine Kombination der Analyse von Annotationen (also PHP-Doccomments) und Signaturen (Typehints) direkt an die erzeugten Instanzen bindet. Die Konfiguration scheint damit sehr viel leichtgewichtiger.

Grails (was so weit ich weiß auf der Spring IOC-Komponente sitzt) geht noch einen Schritt weiter und mappt Instanzvariablen durch reine Naming-Conventions: Wenn also eine Instanzvariable auf “Service” endet und es zur Eigenschaft “mailerService” einen passenden Service “mailer” gibt, wird dieser automagisch injiziert. Kein zusätzlicher Code noch Annotations vonnöten.

Ich wüsste aber nicht, wie man solche Features wirklich performanceneutral, effizient und stabil auf einer Plattform wie PHP aufsetzen könnte – dafür ist die Sprache einfach (noch) nicht weit genug.

Abschließend bleibt ein übler Nachgeschmack – und der Eindruck, dass man sich hier fatal an den XML-“Konfigurationswahnsinn” der entsprechenden Java-“Vorbilder” annähern möchte. Wo doch gerade in diesem Lager intensiv daran gearbeitet wird, genau davon abzurücken und Konfigurationen eben durch Konventionen zu ersetzen.

Was denkt ihr? Kann das ganze doch durch Routine punkten, sodass es durch ein wenig konkrete Projekterfahrung doch ganz leicht von der Hand geht? Wird der DIC im Tagesgeschäft schon intensiv benutzt, oder werden nur die Standardfunktionen des Frameworks verwendet und das Zeug “unter der Haube” doch lieber den Framework- und Bundle-Entwicklern überlassen? Ich bin wieder sehr gespannt auf Meinungen und Kritik…

So gehts nicht:

Doctrine::getTable('propose')
->createQuery('propose')
->select('propose.cat')
->distinct()
->fetchArray();

Denn das wird dazu:

SELECT DISTINCT p.id AS p__id, p.cat AS p__cat FROM propose p

so gehts:

Doctrine::getTable('propose')
->createQuery('propose')
->select('propose.cat as cat')
->distinct()
->fetchArray();

Denn das wird dazu:

SELECT DISTINCT p.cat AS p__0 FROM propose p

Als zukünftige Ausgaben denkbar sind ein Symfony2-basierendes CMF (Content Management Framework) oder eine auf die speziellen Befürfnisse von Online-Shops zugeschnittene Bundle-Sammlung.

Der Code ist noch nicht als stabil deklariert. Die bereits vorhandene und wie immer intensiv gepflegte Referenz-Dokumentation lädt bereits jetzt zum Reinschnuppern und Ausprobieren ein.

<?php

namespace ApplicationHelloBundleEntity;

/**
 * ApplicationHelloBundleEntityUser
 *
 * @orm:Table(name="users")
 * @orm:Entity
 */
class User
{
  /**
   * @var integer $id
   *
   * @orm:Column(name="id", type="integer")
   * @orm:Id
   * @orm:GeneratedValue(strategy="AUTO")
   */
  protected $id;

sollten alle CLI-Tasks auch wunderbar funktionieren. Es bleibt zu hoffen, dass die DI-Services eine reichhaltige Parameter-Dokumentation spendiert kriegen und das ganze Bundle-System eine transparente, dokumentierte API erhalten (wo zum Teufel liegt in der Sandbox bitte der versprochene Doctrine-Controller?)

Die Einstellung findet sich übrigens in der Service-Configuration unter src/vendor/symfony/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml:

<service id="doctrine.orm.metadata_driver.annotation.reader" class="%doctrine.orm.metadata.annotation_reader_class%">
            <call method="setAnnotationNamespaceAlias">
              <argument>DoctrineORMMapping</argument>
              <argument>orm</argument>
            </call>
        </service>

Ist leicht zu finden, wenn man weiß, wonach man suchen muss. Ich denke, es ist am einfachsten, die Service-Definition des DI-Containers an entsprechender Stelle an seine eigenen Bedürfnisse anzupassen. Wie das zuverlässig und projektübergreifend funktioniert, erkläre ich vielleicht mal, wenn ich’s selbst gerafft hab.

Achso, hier noch der Nebensatz (etwas herunter scrollen), in dem gesagt wird, das Jonathan irgendwann mal das “orm:” Präfix einführt. Symfony 2 ist definitiv noch nicht ready for production (was aber auch niemand behauptet).

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.

Für diverse Programmiersprachen gibt es – auf den jeweiligen Anwendungsbereich mehr oder weniger spezialisierte – sogenannte Dependency-Injection (DI)-Container. Der DI-Container als solcher dient im Grunde als Manager oder Konfigurator, der das Zusammenspiel unserer Abhängigkeiten definiert – meist auf Grundlage einer Konfigurationsdatei, die bspw. in XML vorliegt:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <!-- more bean definitions go here... -->

</beans>

(Quelle: Springsource)

Eine weitere Möglichkeit Abhängigkeiten zu definieren, bietet das Convention Over Configuration-Paradigma: Heißt bspw. eine Member-Variable “Mailservice”, so kann der zugrundeliegende DI-Container entsprechend konfiguriert werden, sodass bei Instanziierung automatisch eine Klasse gleichen Namens (Mailservice) instanziiert und an das Objekt gebunden wird (so macht’s bspw. Grails in seinen MVC-Controller-Instanzen, wobei hier natürlich wieder das Spring IoC (Das hat nichts mit dem internationalen olympischen Komitee zu tun, sondern ist die Abkürzung für “Inversion of Control” und steht gleichbedeutend für “Dependency Injection”). Diese Implementierung erfordert natürlich ausgereifte Introspektionsmechanismen der zugrundeliegenden Programmiersprache (Stichwort “Reflection“), außerdem muss man dem DI bzw. IOC-Container vorher beigebracht haben, welche Klassen oder Verzeichnisstrukturen überhaupt durchsucht und unter “DI-Kontrolle” gestellt werden müssen – ein zusätzlicher Programmieraufwand ist also immer noch gegeben. Unvorhersehbarkeiten im Code und eine erhöhte WTF’s/min-Rate kommen dabei frei Haus.

PHP bieted zu dem ganzen Thema ab Werk erstmal – nix. Die Reflection-API ist aber schonmal ein ausgereiftes Werkzeug, um definierte Abhängigkeiten auszuwerten. Das allerdings ausschließlich mittels lesendem Zugriff auf Metadaten von bspw. Klassen, Methoden oder auch System- bzw. benutzerdefinierten Funktionen. Schreibende Operationen sind im Sprachkern erst einmal nicht vorgesehen. Es ist also prinzipiell möglich, zur Laufzeit Abhängigkeiten durch Konvention zu definieren, die Auflösung selbiger ist aber “mit Boardmitteln” nicht zu realisieren.

Ein eigenes Sprachkonstrukt wie Mixins ist auch (noch) nicht implementiert, und anonyme (“Lambda“)-Funktionen lassen sich nicht wie in Javascript oder auch Groovy direkt an den Objekt-Prototypen hängen oder auch an einzelne Instanzen, sondern müssen mühsam “by reference” gezogen und dann erst ausgewertet werden.

Javascript:

  var foo = function() { }
  foo.prototype.bar = function() { return "bar"; }
  foo.baz = foo.prototype.bar;

  var foobar = new foo;
  foo.bar(); // -> "bar"
  foo.baz(); // -> "bar"

PHP:

  $foo = new stdClass();
  $foo->bar = function() 
  {
    return "bar";
  }
  $foo->bar(); // method not found
   
  $bar = $foo->bar;
  $bar(); // -> "bar"

Zugegeben: Gäbe es bereits Mixins oder Prototypen im PHP-Kontext, wäre die Implementierung eines DI-Containers wohl eher unspannend, mindestens aber überflüssig. Dennoch fehlt eine zuverlässige Möglichkeit, PHP-Instanzen zur Laufzeit mit neuen Methoden anreichern zu können. Daher gehen die meisten PHP-DI-Frameworks immer den Weg über einen recht aufgeblähten DI-Container. Dieser macht aber im Grunde nichts anderes, als Referenzen zu verwalten. Der Container selbst wird dann an die anzureichernde Instanz gebunden, im Idealfall eventuell aber noch via magischer Methode __call() verborgen. Dann aber muss die zu aufnehmende Instanz wiederum mindestens ein Interface “Injectable” o.Ä. implementieren. Letzlich aber passiert am Ende immer folgendes:

class myController extends Controller
{
  public function indexAction(HttpRequest $request)
  {
    $db = $this->getService('Database');
  }
}

Der Service-Container übernimmt also die klassische Aufgabe des “ApplicationContext”: Er managed Referenzen, rückt diese aber erst “on demand” heraus. Meiner Meinung hat man dabei nicht allzu viel gewonnen, vor allem, wenn das obige Codeschnippsel noch eine Menge Konfiguration, Code zum Bootstrappen des DI-Containers und/oder Caching voraussetzt.

Ich persönlich würde mir dann doch eher “ganz oldschool” ein paar getter/setter zusätzlich schreiben und mich einfach darauf verlassen, dass der gute, alte ApplicationContext sowieso (fast) alles enthält, was ich brauch’, mit der Konsequenz, dass dieser eben nicht gerade leichtgewichtig ist.

Wozu also das ganze?

Ein alternativer DI-Container mit Doctrine 2 Annotations und Runkit

Die Annotations-Implementierung von Doctrine 2 ist einfach und mächtig genug, um eine beliebigen Klasse mit Metainformationen auszustatten, die die zu injizierenden Abhängigkeiten definieren. Runkit ermöglicht es, auf Basis dieser Metadaten Abhänigkeiten an das ensprechende Objekt zu binden – zur Laufzeit und ohne zusätzliche Implementierung von Schnittstellen o.Ä. Vom Prinzip her sollte es also möglich sein, eine Klasse zu schreiben, diese zu annotieren und dann bei Instanziierung automatisch alle gewünschten Abhängigkeiten zur Verfügung stehen zu haben. Ein Codebeispiel:

index.php:

  require __DIR__ . '/lib/vendor/doctrine-common/lib/Doctrine/Common/ClassLoader.php';

  use DoctrineCommonClassLoader;
  
  $classLoader = new ClassLoader('DoctrineCommon', __DIR__ . '/lib/vendor/doctrine-common/lib');
  $classLoader->register();

  $classLoader = new ClassLoader('deifschleife', __DIR__ . '/lib');
  $classLoader->register();

  // INITIALISIERUNG DES DI-CONTAINERS
  $di_container = new deifschleifediContainer;
  
  $di_container->setClassnames(array(
    'deifschleifeDITest'
  ));
  
  // "AUFNEHMENDE" KLASSE
  $test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Kurz erklärt:

$di_container = new deifschleifediContainer;
$di_container->setClassnames(array(
    'deifschleifeDITest'
  ));

Instanziiert den DI-Container und stellt eine Klasse (deifschleifeDITest) unter seine “Kontrolle”.

$test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Instanziiert die überwachte Klasse deifschleifeDITest und ruft einige Methoden auf, die sämtlich aus anderen Klassen nach DITest injiziert wurden. Die letze Methode ist nirgends existent. deifschleifeDITest implementiert ausschließlich __call(), ansonsten ist die Klasse (fast) leer:

<?php
namespace deifschleife;

/**
 * @Services({
 *   @Service(
 *    class="deifschleifeADependency",
 *    constructorArgs={
 *      "pong"
 *    }
 *  ),
 *  @Service(
 *    class="deifschleifeAnotherDependency",
 *    constructor={"deifschleifeAnotherDependency", "getAnotherDependency"}
 *  ),
 *  @Service(
 *    class="deifschleifeYetAnotherDependency",
 *    constructor="makeYetAnotherDependency"
 *  )
 * })
 */
class DITest
{
  public function __call($method, $args)
  {
    return sprintf("Called __call, Method: %s, Args: %s", $method . '()', implode(', ', $args));
  }

  public function makeYetAnotherDependency()
  {
    return new YetAnotherDependency();
  }
}

Interessant sind die Klassen-Annotationen ganz oben: @Services teilt dem Doctrine 2 Annotation Parser mit, dass hier eine Reihe von PHP-Klassen, die zu injizierende Methoden enthalten, zusammenzusuchen sind. Jeder einzelne @Service in der Liste kann noch grob konfiguriert werden, so kann bspw. eine eigene Factory-Methode für jede Dependency angegeben werden.

Die einzelnen Dependencies sind “ganz normale” PHP-Klassen. Intern passiert folgendes: Die Runkit-Erweiterung dient dazu, über runkit_method_add() “on the fly” eine magische Methode __call() an die mit zusätzlcihen Methoden anzureichernde Klasse deifschleifeDITest zu binden. Existiert bereits eine entsprechende Methode __call(), wird diese intern via runkit_method_rename() umbenannt und am Ende von __call() (neu) aufgerufen. Das bedingt natürlich eine gewisse Rücksichtname bei zusätzlicher Verwendung von __call().

Die Idee unterscheidet sch also nur unwesentlich von bereits vorhandenen Konzepten, spart aber einige Schritte ein:

1.) Man benötigt keine Abstrakte Klasse und/oder Interface, die dass die getService()-Logik bereitstellt.
2.) Man benötigt kaum zusätzliche Konfigurationsaufwand – eine einfache Annotation im PHPDOc-Comment-Format reicht aus (es spricht allerdings nichts dagegen, je nach Gschmäckle einen Config-Adapter dazwischen zu schieben, der das Mapping via XML oder bspw. Yaml erlaubt)
3.) Man kann auf Proxy-Instanzen verzichten, die __call() transparent bereitstellen.

Fazit: Es ist prinzipiell möglich, Dependency Injection – passender noch “Mixins” – mit PHP zu realisieren, ohne nennenswert viel Codeoverhead zu produzieren.

Allerdings muss man berücksichtigen, dass Runkit eine experimentelle Erweiterung ist, deren Zuverlässigkeit in komplexen Projekten nicht vorauszusehen ist. Außerdem wird es sehr wahrscheinlich in Bälde ein mächtiges, neues Sprachkonstrukt geben, das Mixins ermöglicht (siehe RFC zu Traits). Und natürlich kann ich mir auch totalen Murks zusammen gereimt haben, denn sicherlich sind die existierenden Implementierungen von fähigeren Architekten entworfen worden und haben bestimmt ihre Daseinsberechtigungen in einem Kontext, den ich vielleicht einfach noch nicht erfasst haben. Comments dazu wären wir sehr willkommen!

Ausblick

Die Lösung zentral über __call() ist die Schnelle, aber nicht optimale. Vorstellbar ist eine injizierung sämtlicher öffentlicher Methoden wie runkit_method_add, und ein globaler Accessor, der die Objektinstanz der Abhängigkeit liefert. Das ganze könnte man (optional) konfigurierbar gestalten (über Doctrine 2 Annotationen), um eventuellen Namenskonflikten auszuweichen.

Test-Sourcen

Die PHP-Quelltexte zu den obigen Beispielen kann man hier herunterladen:
http://ifschleife.de/dependency_injection.tar.gz

Ich habe die DoctrineCommon-Package bereits beigelegt, das Beispiel sollte also unter PHP5.3 funktionieren (bitte di.php aufrufen, der Rest ist noch durchsetzt mit Doctrine 2 Testklamotten).

Eine Anleitung, wie man Runkit unter php5.3 zum laufen kriegt, gibt es hier (Japanisch, aber der Quelltext ist auf PHP ;))

Die Test-Sourcen liegen, wie in den obigen Codebeispielen beschrieben, unter lib/de/ifschleife. Ich möchte betonen, dass das nur eine Art Fallstudie ist, ich wäre aber über jeden Kommentar erfreut, der mir widerlegt oder bestätigt, ob man den programmatischen Ansatz vielleicht weiterverfolgen sollte.

Vielen Dank für die Aufmerksamkeit! :)

Hier gibt es ein paar Notizen von Jonathan Wage’s Präsentation dazu!

Sehr cool klingt unter anderem auch die writeBehind Geschichte und dass Objekte nicht mehr von Doctrine Klassen abgeleitet werden müssen, sondern mit dem “Entity Managers” zB. gespeichert werden.
Also keine ->save() methoden mehr. :)

“Everything is an entity.” A lightweight persistent domain object, a regular PHP class. You don’t extend a base doctrine class. No final methods.

namespace Entities;
class User
{
private $id;
private $name;
private $address;
}

Note use of namespaces.

EntityManager is central access point to ORM. Used to query for persistent objects. Employs transactional write behind strategy that delays execution of SQL to execute it in the most efficient way.