nikosch

DI-Container Klasse ableiten und erweitern. WO ist das Problem?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

SinnlosS

Eine Datei mehr die ich ändern muss
Wenn ich es nach meiner Methode bequemer finde und statt mit Reflection/serialize/call_user_func_array-Constructor-Injection rumzuhampeln mit Setter-Injection arbeite, wo ist dann da das große Problem? Performance, klar, die wird nach deinem Vorschlag etwas besser sein. Es gehen aber nicht sonderlich viele Calls (dafür eben recht unterschiedliche) pro Request darüber, die Module selber laufen dann meist autark.

Zumindest halte ich es insofern simpel, als ich die Abhängigkeiten über normalen PHP-Code deklariere, statt über Annotations oder zusätzlich ini/xml/sonstwas-files, was ich wiederum nicht mag.

joshiausdemall

Der Symfony DIC (wurde bereits genannt - ich kenne leider daneben keine vernünftige Implementierung im PHP-Umfeld, wie weit die Flow3-Typen sind, weiß ich nicht) konfiguriert via yaml, xml oder Plain-PHP. Addons erlauben mittlerweile sowas wie Autowiring via Convention oder PHPDoc/Annotations.

Die Konfiguration ist sehr teuer - einerseits muss fleißig geparst werden, und auch das Resolving ist nicht ganz ohne.

Daher wird aus der Konfiguration einmalig ein Di-Container erzeugt, der dann nachhaltig zur Verfügung steht. Hier muss nichts erweitert werden oder sonst code-seitig etwas passieren - der DIC ist ein Werkzeug, das einen Erzeuger bereitstellt, der über eine Konfiguration wiederum "sich selbst" persistent generieren kann.

Teure Reflection-Calls sind daher ebenso wie das teure Parsing nicht-nativer Formate wie Yaml kein Problem, da das ganze eben nicht zur Laufzeit passiert. Was dabei heraus kommt, ist ein großer, weg-gecachter "Container", der ausschließlich Getter und generierten Initialisierungscode auf die vorkonfigurierten Services trägt.

Zu den Vorteilen der Geschichte:
Im Grunde ist das ganze eine gute Sache, um sauberen Code zu erzwingen: Schreibt man seine API gegen den Container (oder mit dem Container "In Mind"), spart man sich von vorne herein eine Menge Initialsierungscode, denn der DI-Builder bzw. die Konfiguration nimmt einem genau diese Arbeit ab.

Mit dem Sahnehäubchen, dass alles auch noch schön decoupled bleibt - ein Paradigma, das im Daily Business mal schnell auf der Strecke bleibt - wer was anderes behauptet, lügt

Leider hat das ganze auch einen Nachteil: So ganz rapid ist das Zeug anfänglich nicht, man braucht ein paar Tage, um sich damit als Entwickler von "DI-Controlled Code" anzufreunden. Noch bitterer trifft es den API-User:

Annotation-driven Service Definition und Annotation driven injection/autowiring können hier Abhilfe schaffen. Das klappt performant aber wiederum nur *innerhalb* des Containers - denn der wird *vor* der Laufzeit sozusagen "kompiliert".

Alle Klassen, die den DIC verwenden, aber nicht selbst Service sind (im Symfony-Kontext sind das Klassen, die bspw. ContainerAware implementieren), gucken in die Röhre - denn hier muss wieder Reflection zur Runtime herhalten, um bspw. Annotations oder Naming-Conventions zu interpretieren, wie es bspw. Grails macht ("xyzService" wird automagisch injected, weil "Service" dran hängt). Und selbst sowas würde den Martin F. wahrscheinlich auf die Palme bringen - gerade die Magie ist ja das, was man vermeiden möchte.

Dennoch: Man muss sich die Frage stellen, wo man den "Starting-Point" überhaupt sucht? Klassischerweise ist dieser im Controller zu finden - und es spricht nichts dagegen, Controller gleichfalls als DIC-Managed Service zu definieren - Symfony stellt das zur Wahl.

Also letztlich würde ich das ganze als eine praktische Sache bewerten.

xm22

Das ist aber unflexibel bei Methoden, die etwas komplexer sind, als einfache Setter. Was z. B., wenn man etwas hinzufügen will? Bsp.: Ich habe einen Logger, der eine Add-Methode für Writer hat, welche dann so aufgerufen wird:
Oder was ist, wenn eine Methode einfach mit unterschiedlichen Parametern mehrfach aufgerufen werden soll?
Da kommt man mit einem einfachen Setter nicht weiter. Daher habe ich mir jetzt eine Klasse geschrieben, die mit folgender Konfiguration arbeitet. Inspiriert ist das Ganze von den DI-Containern von Symfony, APF und Yadif.
Das Ganze ist superschlank, dadurch performant und so flexibel, dass man alle Fälle, die mir eingefallen sind, abdecken kann.

Wenn es mehr als 1 $arg gibt, wird das Objekt per Reflection instanziiert, ansonsten einfach per Konstruktor. Wenn Methoden mehr als einen Parameter haben, kommt call_user_func_array zum Einsatz, ansonsten wird einfach die entsprechende MEthode aufgerufen.