xm22

Hallo,

ich bin gerade an einem Problem, zu dem ich bis jetzt keine "richtige" Lösung güt mich finden konnte. Und zwar stelle ich mir die Frage, wie man in einer Applikation auf die Applikations-Konfiguration zugreift. In meinem Fall ist das ein Objekt ähnlich Zend_Config.

Bisher ist mein Ansatz folgender, mit dem ich aber sehr unzufrieden bin. Das Konzept ist ähnlich wie hmvc:

Ich habe, wie gesagt, ein Konfigurationsobjekt. Dieses enthält sämtliche Konfigurationen zu der Applikation. Das führt natürlich dazu, dass es an den verschiedensten Stellen benötigt wird. Daher war mein Ansatz bisher der, dass ich den Applikationsknoten (Entspricht etwa einer Action im mvc-Prinzip) und den jeweiligen Views dieses Objekt im Konstruktor übergeben habe, so dass gesichert ist, dass es auch vorhanden ist.

Das Problem dabei ist, dass viele andere Objekte - z. B. irgendwelche Plugins, aber eben nicht alle, ebenfalls Zugriff auf die Konfiguration benötigen. Das habe ich bisher so gelöst, dass ich hier den Plugins, die die Konfiguration benötigen, diese mit übergebe. Allerdings ist das sehr frickelig und unflexibel.

Jetzt habe ich folgende Ansätze, die in meinen Augen aber alle nicht ganz gar sind:

1. Singleton (Evtl. mit Parameter, um mehrere verwalten zu können, also etwa so:
2. Per Registry
3. Per DI in JEDES Objekt
4. Ein Applikationsobjekt, etwa wie bei dem Kohana-Framework, also etwa so:
Mittlerweile tendiere ich zu Punkt 3, da alle Objekte letztendlich von einer einzigen Oberklasse ("Object") abgeleitet werden und das dort relativ leicht zu implementieren wäre. Daraus leitet sich dann ein evtl. 5. Punkt ab, nämlich als statische Eigenschaft von "Object", also so:
Eine manuelle Übergabe kommt für mich nicht in Frage, weil das einfach zu unflexibel und aufwändig ist.

Was ist eure Meinung dazu?

Mister Ad

papst23

Ich habe das bis jetzt immer mit DI gelöst. Das hat den Vorteil, das man für Tests auch einfach nur die Globle config anpassen muss und so z.B. gegen eine Test DB testen kann.

Allgemein kann man sich das Prinzip auch sehr gut bei Spring (Java-Welt) ansehen. Da Arbeitet man dann viel mit configurations XMLs oder Mockups um teile der Application getrennt entwickeln und testen kann. Was auch den großen Vorteil von loser Kopplung hat, wo man jeden teil der Application austauschen und einzelnt wiederverwenden kann.

Gruß
René

xm22

DI hat in meinen Augen jedoch auch immer den Nachteil, dass man diesen Mechanismus ebenfalls wieder überall implementieren muss..

Koala

nein, eben nicht überall:

xm22

Eben doch, da ja der Ansatz generisch sein soll. Vielleicht habe ich mich oben falsch ausgedrückt. Im Moment haben nur die Plugins Zugriff auf die Config, die sie auch benötigen. Aber eben das ist unflexibel. Daher will ich es so machen, dass der Zugriff von überall möglich sein soll.

Koala

das ist doch die gleiche Diskussion wie bei dem DB-Objekt das überall verfügbar sein soll
(egal, ob eine andere Klasse es benötigt oder nicht). Quasi "globale Objekte".

Ich dachte immer ein wesentliches Merkmal der OOP sei Kapselung und daß eben gerade NICHT
alles überall verfügbar sein soll.

Oder noch "ketzerischer" ausgedrückt: verzichte auf OOP, dann ist Deine Konfiguration überall verfügbar.

würd ich nicht machen: eine Konfiguration muß auch zur Laufzeit änderbar sein (z.B. im Adminbereich).

papst23

Du könntest die Plugins natürlich auch über ein Observer Pattern implementieren, so dass du an gewissen Stellen in dennen du Plugins anbieten willst einfach das Observable Interface Implementierst, dass seinen ganzen Context ($this) an die Listener bzw. deine Plugins übergibt. Dann kannst du ganz normal deine DI konfigurieren und dann trozdem dynamisch Plugins registrieren, die dann über den Context auf verschiedene Konfigutationen zugreifen (wie z.B.: ein DB-Objekt oder Registry-Objekt)

gruß
René

xm22

Mmh... Wäre auch eine Idee, allerdings wäre dieser Ansatz dann wieder beschränkt auf die Plugins und für alles andere müsste ich mir wieder etwas anderes überlegen.

nikosch

Warum injectest Du die jeweils benötigten Einstellungen (nicht das ganze Conf-Objekt) nicht von außen in die Methode?

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

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

xm22

Das Problem, dass ich bei DI sehe, ist, dass ich dann _jedes_ Objekt bei DI-Container o. ä. aufrufen müsste. Ich habe mich mal bei asp.net umgesehen und da ist es so, dass die App-Config oder wie das bei denen heißt, per statischer Methoden bzw. einer Art Singleton gehandhabt wird. Bei jsf/jsp ist es ebenso. Daher tendiere ich jetzt mittlerweile auch wieder mehr zu diesem Ansatz.

Das ist aber auch schwer zu entscheiden...