dsentker

Hallo,

beim Erstellen meines Frameworks habe ich bis jetzt auf Singleton verzichtet (bis auf Factories). Auch meine ursprüngliche Überlegung, den FrontController als Singleton zu realisieren, scheiterte kläglich, als ich versucht habe HMVC-ähnliche Knoten aufzurufen. Daher wird dieser nun, wie es sich gehört, normal instanziiert.

Hintergrund zum FC:
Ein Request landet beim FrontController. Der FC zieht dann den Router hinzu und wertet den Request aus. Der FrontController generiert dann mit diesen Daten und mit Hilfe eines ControllerBuilders (eine Art Factory) dann den Controller. Vor dem Ausführen der eigentlichen Action übergibt sich der FrontController nochmal selbst an den Controller. Das liegt daran, dass der FrontController Objekte enthält wie Config, Request, ServiceContainer etc, auf die man im Controller stets Zugriff haben sollte.

Ich bin so fixiert auf den FrontController, da dieser den Request, die Config, den Router oder auch den ServiceContainer (DI-Container) beinhaltet.

Nun kommen externe Komponenten ins Spiel: Als Beispiel nehme ich mal einen Logger, der nicht fester Bestandteil des Frameworks ist. Ein Writer dieses Loggers, etwa FirePHPWriter, muss auf meinen FrontController zugreifen könne, um den ServiceContainer zu bekommen, der wiederum eine Instanz von FirePHP spendet.

(Alternative: Der DatabaseWriter muss auf den Service 'PDO' zugreifen.)

Als mein FC noch Singleton war, konnte ich bequem sagen
Aber das geht ja nun nicht mehr, weil der ServiceContainer bzw. der FrontController nicht mehr global ansteuerbar ist.

Ich habe mir gedacht, nur den ServiceContainer als Singleton zu gestalten. Dieser ServiceContainer beinhaltet dann auch den Router, die Config etc.

Das widerspricht aber etwas meinem Prinzip, dass der ServiceContainer keine Framework-eigenen Objekte verwaltet.

Habt ihr eine Idee?

__________________

Mister Ad

nikosch

Komponente generell mit Controller/ServiceContainer-Instanz instanziieren?

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

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

dsentker

Ja, mein Problem hat sich wohl erledigt. Die Config mache ich nun doch als Registry (sprich, Singleton) und externe Komponente selbst brauchen nicht auf den Service Container zuzugreifen, da sie selbst Teil des Containers sind. Diese werden dann nur im Controller angefragt.

__________________

xm22

Ich habe das bei mir so gelöst, dass es pro Request ein "Context-Objekt" als Singleton gibt, dass alle relevanten Objekte, die man innerhalb der Applikation benötigt, enthält (Request, Response, DIC, Konfiguration, etc.). Der Aufruf gestaltet sich dann so:
Jetzt werden wieder einige aufschreien und meckern, dass das nicht besonders sauber sei. Aber: Ich habe wirklich lange an dem Problem gesessen und wenn man HMVC so umsetzen will, wie ich das in meinem Framework (Heißt, HMVC-Knoten sollen an jeder Stelle benutzt werden können), dann MUSS man irgendwo eine zentrale Stelle haben, die alle notwendigen Informationen enthält.

mquadrat

Bei uns gibt es auch einen Kontext. Nur andersrum als bei xm22. Sprich der Kontext ist eine Eigenschaft des Requests und der wird via manueller Injektion durchgeschleift.

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

xm22

Das klingt gut. Was enthält bei euch das Kontext-Objekt?

dsentker

@xm22
Aber bekommst du durch dein Context-Singleton keine Probleme? Wenn es einen internen Subrequest gibt, kann ZNApplicationContext doch nicht neu kreiert werden. Das bestehende Singleton wird demnach überschrieben. Somit hast du keine Kontrolle mehr über vorherige Stati, nachdem ein Subrequest ausgelöst wurde. Wie löst du das?

__________________

xm22

Das Problem stellt sich in der Tat - Allerdings ist die Wahrscheinlichkeit, dass so etwas geschieht, meiner Erfahrung nach extrem gering. Aber ich bin jetzt am Überlegen, ob ich das Context-Objekt nicht doch durchreiche, da mir die Singleton-Lösung nicht besonders gut gefällt. Was mich bis jetzt daran gestört hat, war, dass auch das View dann das Context-Objekt explizit übergeben bekommen muss - Auf der anderen Seite greift es stattdessen über ein Singleton darauf zu, was eigentlich noch schlimmer ist.

Daher tendiere ich dazu, dass Context-Objekt doch manuell an Components (entsprechend Controllern) und Views durchzureichen.

dsentker

Ich überlege gerade, ob man nicht ein Singleton-Request-Wrapper-Objekt realisieren sollte. Jeder "neue" Reguest innerhalb der HMVC-Knoten wird dann im RequestWrapper-Stack gespeichert. Der Request selbst beinhaltet dann auch den DI-Container, die Konfiguration etc...

Also
Interessant wird es dann, wenn man die Subrequests nicht anhand einer Nummer (wie o.g.) aufruft, sondern wenn jeder Subrequest benannt ist, so dass jeder Subrequest anhand eines Namens identifiziert werden kann. Nur eine spontane Eingebung.
Was mich stört, ist, dass der Request dazu missbraucht wird, Container und Config mit sich rumzuschleppen.

__________________

xm22

Was mich an diesen Subrequests stört, ist, dass das so klingt, als würde der komplette Dispatch-Prozess noch mal angestoßen. Mein Verständnis von HMVC ist, dass die einzelnen Knoten innerhalb des selben Life-Cycles benutzt werden sollten, weil sonst ein enormer Overhead entsteht.