Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Methodenverkettung

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Methodenverkettung

    Hallo, ich versuche mein Problem zu schildern: Ich arbeite nach dem MVC-Pattern, Sprich: Im Hauptprogramm nimmt der Controller Requests entgegen und delegiert diese an das Model weiter. Da meine Model Klasse aus einer weiteren Unterklasse besteht, sieht mein Code wie folgt aus:

    PHP-Code:
    $c = new Controller();
    $c->delegate($_GET['email']);

    class 
    Controller{

        public function 
    Controller(){
            
    $this->model = new Model();
        }

        public function 
    delegate($param){
            
    $this->model->executeBla($param);
        }

    }

    class 
    Model{

        public function 
    Model(){
            
    $this->subModelClass = new SubModelClass();
        }

        public function 
    executeBla($param){
            
    $this->subModelClass->callThis($param);
        }

    }

    class 
    SubModelClass{

        public function 
    callThis($bla){
            
    //hier die eigentliche Verarbeitung
        
    }


    Ist das so gängige Praxis? Oder kann man das in etwa verbessern. Was mir auffällt, ist die Methodenverkettung, die über die Klassen hinweg stattfindet. Entfernt man diese Methode, müssen alle anderen Klassen auch geändert werden, was ja eigentlich OOP-Prinzipien verletzt. Zusätlich möchte ich gerne wissen, wo man dabei am geschicktesten die Validierung der Parameterübergabe einbaut, also nur in der SubModelClass, oder in allen anderen auch. Vielen Dank im Vorraus.


  • #2
    hey PHPython,

    also in sf2 macht sowas ein Router. Du gibst Routen an und im Request Hook wird dann geprueft, ob die URL mit einer ROute zusammenpasst. In der Route Configuration befindet sich dann meistens ein String, der den Controller angibt und in einem Controller Resolver zu einem callable umgebaut wird.
    Manche machen jetzt den Fehler, die gesamte Logik in den Controller zu bauen. Das wird spaetestens dann bloed, wenn man fuer einen UseCase auch einen CLI Command implementieren muss..

    Nun ja, MVC ist IMHO nicht die optimalloesung: http://www.php.de/software-design/10...die-tonne.html
    wie waers, wenn du dir mal DDD ansiehst und dann eine Moeglichkeit kennenlernst, das Modelsauber zu implementieren?
    hier mal eine in C# geschriebene DDD Implementierung: http://gorodinski.com/blog/2012/04/1...en-design-ddd/

    DU wirst dich jetzt fragen, wieso C#, da das ja nichts mit dem Web zu tun hat, du koennstest aber den Model layer auch so implementieren und dann den Application Service vom Controller aufrufen (so etwa mach ich das aktuell)

    Nun noch etwas zu deinem Code:
    1.: wieso nutzt du nicht __construct() sondern nutzt den Klassennamen als Constructor? http://stackoverflow.com/questions/2...tructor-in-php

    2.: an deinen constructoren sieht man, dass du dir mal dependency injection ansehen solltest: http://de.wikipedia.org/wiki/Dependency_Injection

    Es ist besser, Abhaenigkeiten zu injecten, statt diese direkt im constructor zu instanziieren.
    Dadurch gibt es keine expliziten Abhaengigkeiten mehr, sondern man kann einfach ein Interface als TypeHint zu setzen und dann die konkreten implementierungen dder services einfacher austauschen und die klasse besser einem unit test unterziehen

    Ich hoffe, ich habe dir etwas geholfen und das war soweit korrekt

    LG
    https://github.com/Ma27
    Javascript Logic is funny:
    [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

    Kommentar


    • #3
      Die Prolematik ist ja nur, dass der Controller sämtliche Delegationen entgegennimmt. Injiziere ich die Abhängigkeiten, so kann ich zu Beginn bereits schreiben:

      PHP-Code:
      $s = new SubModelClass();
      $s->callThis($_GET['email');
      //... 
      Und so die Klassen zusammenbauen. Würde das aber nicht dagegen sprechen, dass der Controller ausschließlich für das Entgegennehmen/Absetzen von Requests/Responses verantwortlich ist (in diesem Fall setze ich ja SubModelClass für Entgegennahme ein). Diese Lösung hat jedoch den Vorteil, keine "wrapper-Methoden" in den anderen Klassen zu haben.

      @ma: Und ich denke Routen haben bei diesem Thema nichts mit zu tun, da ich lediglich nach der Kommunikation zwischen den Klassen frage, und nicht mit URLs arbeite. Ich danke dir jedoch für deine Antwort.

      Kommentar


      • #4
        @ma: Und ich denke Routen haben bei diesem Thema nichts mit zu tun, da ich lediglich nach der Kommunikation zwischen den Klassen frage, und nicht mit URLs arbeite. Ich danke dir jedoch für deine Antwort.
        ach du meinst die kommunikation zwischen klassen.
        da wuerde ich auch mit Dependency Injection arbeiten (s.o)

        der controller nimmt im prinzip den request entgegen. Da koennntest du aus einem Request Objekt die noetigen daten aus dem Request holen.
        Nun kannste nen Application Service/whatever (siehe DDD) aufrufen mit den Parametern aus dem Request, falls das noetig ist

        LG
        https://github.com/Ma27
        Javascript Logic is funny:
        [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

        Kommentar


        • #5
          Hallo, ich versuche mein Problem zu schildern: Ich arbeite nach dem MVC-Pattern,
          Naja, mein persönlicher Vorschlag wäre, Du liest Dich in das Thema MVC erst mal ein wenig ein:

          http://phpmagazin.de/artikel/Model-V...ndungen-171912
          http://phpmagazin.de/artikel/Was-nic...-Teil-2-171917

          schaust Dir dann im Detail die gängigen „Implementierungsversuche“ von MVC im Webkontext an z.B. bei Symfony2 oder ZF2 und fängst danach ganz von vorne an

          vg
          jack
          -

          Kommentar


          • #6
            strenggenommen ist Symfony kein MVC und das was Leute MVC schimpfen ist es IMO auch nicht wirklich: http://fabien.potencier.org/article/49/what-is-symfony2
            https://github.com/Ma27
            Javascript Logic is funny:
            [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

            Kommentar


            • #7
              Nochmal zur Erläuterung, weil ich glaube, dass ich mich undeutlich ausgedrückt habe. Es geht mir darum, dass ich Antworten bzgl. der Methodenverkettung haben möchte. Oben wird $c->delegate aufgerufen, doch diese Methode ruft schlussendlich nur weitere Methoden auf, die Methoden aufrufen, bis es bei der Methode mit der Bearbeitungslogik endet. Und hier wollte ich wissen, ob ich diesen Weg gehen sollte, oder direkt in der Initialisierung SubModelClass den Get-Wert direkt übergebe, und dann das Objekt weiter injiziere. Dadurch verletze ich aber imho MVC-Praxis, da der Controller für Delegationen zuständig sein sollte und Requests entgegennehmen sollte. Könnt ihr mir helfen?

              Kommentar


              • #8
                MVC-Praxis
                wie schon gesagt, richtiges MVC gibt es im Web nicht. Sieh dir mal die sf2 Loesung an lies dir mal die von mir geposteten Links durch

                da der Controller für Delegationen zuständig sein sollte und Requests entgegennehmen sollte. Könnt ihr mir helfen?
                der Controller nimmt den Request entgegen und ruft einen zustaendigen Application Service auf. Der Controller ist nun auch noch dazu da, um dass, was beim Service bei rauskommt, fuer die Response umzuformen
                https://github.com/Ma27
                Javascript Logic is funny:
                [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                Kommentar


                • #9
                  strenggenommen ist Symfony kein MVC
                  Richtig, genauso wenig wie ZF2 und alle die anderen. Allerdings versuchen sich alle diese Frameworks letztendlich doch irgendwie mehr oder weniger schleichend am MVC zu orientieren, z.B. indem sie sich konzeptionell an MVC anlehnen und MVC-Begrifflichkeiten wie Controller, View und Model verwenden.

                  Symfony1 hat man z.B. noch als MVC-Framework beworben

                  http://symfony.com/legacy/doc/book/1...implementation

                  dann hat man in SF2 einfach auf das "Model Layer" verzichtet und nun ist es kein MVC mehr, den Controller und View hat man allerdings weiterhin behalten:

                  „And if you like to call Symfony2 an MVC framework, then you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM. „

                  Also ein VC-ohne-M FM oder was

                  Die großen Frameworks sind meiner Ansicht nach deshalb auch die Hauptschuldigen an der Verwirrung rund um MVC .

                  vg
                  jack
                  -

                  Kommentar


                  • #10
                    Wenn wir konkret bei der Frage bleiben könnten, und kein neues Fass aufmachen, wäre das im Interesse des TE denke ich. Ich halte die Vorgehensweise für richtig, jedenfalls mache ich das selbst auch so, dass der Controller Requests annimmt, diese prüft und dann an die jeweilige Modelinstanz weitergibt. Dass dabei Verkettungen entstehen ist nicht zu verhindern. Das ist jedoch sauberer als dem Model die Daten direkt bei der Instanziierung zu geben.

                    Kommentar


                    • #11
                      naja ne richtige view gibt es auch nicht. Symfony returned im Controller halt ne Response, die halt ein gerendertes Template enthalten kann.

                      Joa es gibt diese Entities und wenn man korrektes DDD einsetzt, hat man auch wieder Models, aber das Prinzip von MVC geht nicht auf..

                      puh ich bin ja so froh, dass ich sf1 nicht miterlebt habe und dafuer zu jung bin
                      https://github.com/Ma27
                      Javascript Logic is funny:
                      [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                      Kommentar


                      • #12
                        Wenn wir konkret bei der Frage bleiben könnten, und kein neues Fass aufmachen, wäre das im Interesse des TE denke ich
                        ich gebe ja weiterhin antworten auf seine fragen, aber es sollte halt, wenn man sicht mit so etwas auseinandersetzt, auch darueber geredet werden..
                        https://github.com/Ma27
                        Javascript Logic is funny:
                        [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                        Kommentar


                        • #13
                          Wie ich das verstanden habe will er die Verkettung von
                          delegate=>executeBla=>callThis
                          verkleinern, da delegate() und executeBla() keinen wirklichen Mehrwert bieten, sondern nur den Wert vom Controller durchreichen.

                          Kommentar


                          • #14
                            Genau das meine ich. Hast du einen Vorschlag?

                            Kommentar


                            • #15
                              Dadurch verletze ich aber imho MVC-Praxis, da der Controller für Delegationen zuständig sein sollte und Requests entgegennehmen sollte.
                              Also wie gesagt, ich denke Du bist da konzeptionell ein wenig auf dem Holzweg. Der Controller in einer Webapplikation ist normalerweise weder für Delegationen noch für das Entgegennehmen von Requests zuständig. Abgesehen davon handelt es sich bei der Controllermethode delegate() nicht um eine Delegation (im Sinne von OOP).

                              Eine Methode wie delegate() hat in einem Controller also nichts verloren. Wenn schon genau eine Aufgabe/Controller dann benenne die Methode besser als execute(), oder mach den Controller gleich callable/invokable.

                              Das Beispiel in Post 1 ist leider derart konstruiert, dass es schwer fällt einen sinnvollen Vorschlag zu machen. Grundsätzlich sehe ich in darin jedoch keinen Verstoß gegen das Gesetz von Demeter.

                              vg
                              jack
                              -

                              Kommentar

                              Lädt...
                              X