Trainmaster

Je nach Implementierung kann ein DI-Container selbstverständlich mehr. Für deinen Fall würden mir momentan drei Lösungen einfallen:

• Factory als Service
• Bei der Service-Konfiguration einen Flag setzen, ob bei jeder Service-Anforderung ein neues Objekt erzeugt werden soll oder nicht
• Der get()-Methode einen optionalen Flag spendieren und entsprechend entweder ein neues Objekt erzeugen oder, sofern das Objekt bereits erzeugt wurde, dieses zurückgeben.

Nachdem ich gerade selbst an einer Implementierung eines DI/Service-Containers für mein Framework arbeite, bin ich noch unentschlossen, welche Variante ich favorisieren soll. Erstere scheint mir bisher am Saubersten zu sein.

Mister Ad

dsentker

Also ein Bestimmen ob "Singleton oder nicht" zur Laufzeit?

__________________

Trainmaster

Ja, aber das gilt nur für Letzteres.

Wieso zwangsläufig service locator?

mquadrat

Du musst sogar alle Fälle über die gleiche Methode abhandeln. Sonst braucht der Aufrufer ja wieder Informationen über den Service und die Kopplung wird wieder enger.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

xm22

Sehe ich auch so.

dsentker

Du meinst den Fall, wenn Service A1, der Singleton ist, irgendwann mal durch den moderneren Service A2 ausgetauscht wird und nun nicht mehr Singleton ist? Das sehe ich ein, zwei verschiedene Methodenaufrufe sind Unsinn. Im Umkehrschluss heisst das dann ja auch, das tatsächlich der Service selbst bestimmt, ob er Singleton ist oder nicht. Und nicht der Aufrufer.

__________________

mquadrat

Korrekt.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

dsentker

Okay, also keine create()-Alternative zum get() im Container. Ich werde dann nun Factories ebenfalls als Services implementierbar machen.

__________________

Trainmaster

Nachdem ich nun etliche Stunden mit der Lektüre von DI, DICs, IoC, Service Locator und Factories verbracht habe, ist mir die ganze Thematik klarer geworden. Eine zentrale Erkenntnis ist, dass DIC-Container zumeist als Service Locators verwendet werden. Allein die Anforderung eines Service innerhalb eines Controller über bspw. eine get()-Methode stellt bereits diesen Fall dar. Konsequentes DI würde bedeuten, von der Wurzel an per Injiektion zu arbeiten.

Gerade in Verbindung mit MVC scheint es nicht trivial zu sein bzw. ist ein hoher Aufwand nötig, um konsequent DI einzusetzen zu wollen. Sollten selbst Action-Methoden via Injizierung ihre Abhängigkeiten erhalten, ist es entweder nötig dem Controller per Konfiguration die entsprechenden Abhängigkeiten zu injizieren und somit in den Action-Methoden verfügbar zu machen, oder aber, sofern die Action-Methoden unterschiedlichste Services nutzen und es nicht gewollt ist, diese alle dem Controller zu injizieren, weil zur Laufzeit nur ein Teil davon benötigt wird, wird es nötig, eine eigene Konfigurationen für die Action-Methoden bereitzustellen, um den individuellen Bedürfnissen, sprich Abhängigkeiten, nachzukommen. Meiner Meinung nach wäre das ein glatter Konfigurationswahnsinn.

dsentker

Ja, aber nur dann wenn du DI Wirklich von der Wurzel an planst. Ein DI-Prozess kann ja auch angestoßen werden, nachdem mehrere "fest verankerte" Komponente integriert wurden, etwa der Controller. Ich denke, mit meiner Realisierung bin ich einen vernünftigen Mittelweg gegangen.

__________________