Ankündigung

Einklappen
Keine Ankündigung bisher.

MVC und vergleichbare und Applikations-Config

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MVC und vergleichbare und Applikations-Config

    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:
    PHP-Code:
    Config::getInstance('name'); 
    2. Per Registry
    3. Per DI in JEDES Objekt
    4. Ein Applikationsobjekt, etwa wie bei dem Kohana-Framework, also etwa so:
    PHP-Code:
    Application::config->... 
    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:
    PHP-Code:
    Object::config->... 
    Eine manuelle Übergabe kommt für mich nicht in Frage, weil das einfach zu unflexibel und aufwändig ist.

    Was ist eure Meinung dazu?

  • #2
    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é
    [URL="http://penner.name"]mein blog[/URL]

    Kommentar


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

      Kommentar


      • #4
        DI hat in meinen Augen jedoch auch immer den Nachteil, dass man diesen Mechanismus ebenfalls wieder überall implementieren muss..
        nein, eben nicht überall:
        Das Problem dabei ist, dass viele andere Objekte - z. B. irgendwelche Plugins, aber eben nicht alle, ebenfalls Zugriff auf die Konfiguration benötigen.
        Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            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.

            nämlich als statische Eigenschaft
            würd ich nicht machen: eine Konfiguration muß auch zur Laufzeit änderbar sein (z.B. im Adminbereich).
            Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

            Kommentar


            • #7
              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é
              [URL="http://penner.name"]mein blog[/URL]

              Kommentar


              • #8
                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.

                Kommentar


                • #9
                  Warum injectest Du die jeweils benötigten Einstellungen (nicht das ganze Conf-Objekt) nicht von außen in die Methode?
                  [COLOR="#F5F5FF"]--[/COLOR]
                  [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                  „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                  [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                  [COLOR="#F5F5FF"]
                  --[/COLOR]

                  Kommentar


                  • #10
                    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...

                    Kommentar


                    • #11
                      DI heißt nicht zwingend Container. Auch das ist DI:

                      PHP-Code:
                      $conf Configs::get('myClassNamespace');

                      $mC = new myClass ($conf['color']);
                      echo 
                      $mC->getOutput ($conf['size']); 
                      oder:
                      PHP-Code:
                      $mC = new myClass;

                      $conf Configs::get($mC->getNamespace ());
                      $mC->setConfig ($conf); 
                      [COLOR="#F5F5FF"]--[/COLOR]
                      [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                      [COLOR="#F5F5FF"]
                      --[/COLOR]

                      Kommentar


                      • #12
                        Ah, ok.. So kannte ich das gar nicht. Eine Frage noch, gerne auch mit Link als Antwort: Im zweiten Bsp.: Was ist da myClass?

                        Kommentar


                        • #13
                          Verstehe die Frage nicht. Das ist ein Beispielname. Ich hätte auch $foo = new fooBar; schreiben können.
                          [COLOR="#F5F5FF"]--[/COLOR]
                          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                          [COLOR="#F5F5FF"]
                          --[/COLOR]

                          Kommentar


                          • #14
                            Nee, schon klar Vielleicht sehe ich ja den Wald vor Bäumen nicht. In dieser Klasse scheint es hier jetzt eine Funktion getNamespace zu geben. Meine Frage bezieht sich also nicht auf den Namen der Klasse, sondern was diese Klasse für eine Funktionalität bereit stellt.

                            Kommentar


                            • #15
                              Naja, konkreter gehts nicht, weil ich auf Deine abstrakte Frage antworte.
                              [COLOR="#F5F5FF"]--[/COLOR]
                              [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                              [COLOR="#F5F5FF"]
                              --[/COLOR]

                              Kommentar

                              Lädt...
                              X