Ankündigung

Einklappen
Keine Ankündigung bisher.

Controller inkl. oder exkl. Action

Einklappen

Neue Werbung 2019

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

  • Controller inkl. oder exkl. Action

    Hallo,

    ich wollte mal eure Meinung zu meiner Frage hören. Und zwar geht es darum in einem HMVC die Action mit an den Controller zu binden.

    Normalerweise sieht eine URL zum Beispiel so aus:
    /controller/action/param1 (z.B. /guestbook/edit/1)

    Man hat also eine Controller-Klasse die mehrere Actions beinhalten kann.

    Nun habe ich da in Richtung Speicherverbrauch gedacht (warum immer Actions laden wenn Diese garnicht benötigt werden).

    Wenn man die URL nun so umbaut:
    /controllerAction/param1 (z.B. /guestbookEdit/1)

    So hat man nicht ein riesen Controller sondern mehrere Kleine (Resultat wären mehrere Datein).

    Vorteile:
    - Speicherverbrauch wird reduziert
    - Wartbarkeit vereinfacht (da es seltener Datein mit 1000 Zeilen Code gibt)

    Nachteile:
    - Mehr Dateien (da somit auch jede Action eine View bräuchte [auch wenns nur ein blanko ist])

    Vielleicht verfolgt auch schon jemand so ein vorhanden, ich konnte bislang jedenfalls kein Framework auf dieser Basis finden.

    So, dann kann diskutiert werden

  • #2
    Zitat von stayInside Beitrag anzeigen
    Vielleicht verfolgt auch schon jemand so ein vorhanden, ich konnte bislang jedenfalls kein Framework auf dieser Basis finden.
    Würde mich auch wundern, wenn du ein FW finden würdest, welches so etwas macht. Denn es macht in meinen Augen gar keinen Sinn. Du würdest das selbe erzielen, wenn du für jede dieser Controller eine eigene Datei machen würdest ohne Klassen, zumal auch noch wesentlich einfacher und schneller.
    Der Controller Guestbook, soll alle Gästebuch spezifischen Anfragen managen, daher sollten auch alle Actions in diese Klasse kommen. Es macht IMHO keinen Sinn einen Controller für GB- editieren, neuer Eintrag erstellen, löschen und lesen zu estellen. Das gehört alles in einen Controller. Und so groß sind die Klassen in der Regel sowieso nicht!
    "My software never has bugs, it just develops random features."
    "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

    Kommentar


    • #3
      Zitat von Paul.Schramenko Beitrag anzeigen
      Der Controller Guestbook, soll alle Gästebuch spezifischen Anfragen managen, daher sollten auch alle Actions in diese Klasse kommen. Es macht IMHO keinen Sinn einen Controller für GB- editieren, neuer Eintrag erstellen, löschen und lesen zu estellen. Das gehört alles in einen Controller.
      Ist Ansichtssache, man kann einen Controller auch als Unterverzeichnis auffassen und eine Action als separate Klasse mit der Methode execute(). Also ich finde das ok, auch hinsichtlich um den Code aufzuteilen, auch wenn du nicht soviel schriebst

      Im Buch PHP Design Patterns Von Stephan Schmidt gab es glaube ich ein ähnliches Vorgehen beim CommandResolver. Obs in Frameworks in der Praxis angewendet wird, kann ich mangels Erfahrung nicht sagen.

      Kommentar


      • #4
        Gibt es denn irgendwelche "Richtlinien" ab wann man ein neuen Controller macht bzw. ab wann eine Action ein Controller ist?

        Zum Beispiel ein User Profil:
        Es gibt den Unterpunkt Fotos und Videos. Wäre UserFotos und UserVideos jeweils ein Controller?

        In unserer Firma verfolgen wir nämlich genau die Logik aus meinem 1. Posts. Da ich allerdings noch in der Ausbildung stehen weiss ich natürlich nicht was besser/schlechter ist.

        Kommentar


        • #5
          Das ist dir überlassen. Ordne deine Controller/Action so an das sie möglichst übersichtlich sind und Dinge die zueinander gehören auch zusammen stehen.

          Kommentar


          • #6
            Die Wartbarkeit wird dann erhöht, wenn deine Methoden kürzer werden und nicht dadurch, dass die gleichen Methoden einfach auf mehr Dateien aufgeteilt werden

            Kommentar


            • #7
              Bei einem 1000-zeiligen Controller hast du dir den Einsatz von Models gespart, oder? "Skinny controllers, fat models."

              Der (konsequentere) Einsatz von Models dürfte dieses "Problem" lösen:

              Nun habe ich da in Richtung Speicherverbrauch gedacht (warum immer Actions laden wenn Diese garnicht benötigt werden).
              Überlegungen hinsichtlich Speicherverbrauch sind grundsätzlich natürlich immer gut, aber sie sollten für das Erstellen und Anordnen von Quellcode-Dateien niemals über inhaltlichen Aspekten stehen.

              Der Gedanke darf nicht "Diese Klasse ist 20 kb groß, das muss alles immerzu geladen werden." sein, sondern "Es ist für mich als Programmierer schwierig, diese Klasse/Methode zu überblicken, weil sie viele Dinge auf einmal erledigt. Vielleicht gibt es eine sinnvolle Möglichkeit, sie weiter zu unterteilen.".

              Kommentar


              • #8
                Wenn du nen Opcode Cacher verwendest hast du ja auch nicht mehr das Problem mit der "Geschwindigkeit" da sind eh alle PHP Files im Arbeitsspeicher.

                Und da du in Controller Klassen ja meist nur eine einzige Methode anschaust, die Aktion eben, ist es fast egal wie lang die Datei ist. Mit nem richtigen Editor hast du meist auch so nen "Outline/Navigation" View der dir alle Methoden auflistet, somit kannst du super schnell in der Klasse rumspringen und musst nicht viele Zeilen scrollen. Dadurch hab ich teilweise Controller die an die 1500 Zeilen haben, weil eben alles einzelne Aktions sind die zusammengehören.

                Kommentar


                • #9
                  Stimmt. Ein Opcode Cache soll später eingesetzt werden. Aber wirklich dran gedacht habe ich nicht :P

                  Dann allerdings nochmal die Fragen.

                  Zum Beispiel ein User Profil:
                  Es gibt den Unterpunkt Fotos und Videos. Wäre UserFotos und UserVideos jeweils ein Controller? Oder wäre User ein großer Controller?

                  Kommentar


                  • #10
                    Kommt drauf an, wie umfangreich das ganze ist. Wenn es nur ein einfaches Anzeigen ist, dann gehört das Entweder in den User-Controller oder besser in den Gallery-Controller, falls so einer existiert.

                    Wenn dadrin auch gleich upload, löschen und editieren geregelt wird, würd ich UserFotos und UserVideos in eigene Controller auslagern.

                    Kommentar


                    • #11
                      Ich hab alles in einem UserController, dabei wird jede Menge gemacht, der ist entsprechend auch auf 1600 Zeilen angewachsen, aber mit bissl Refactoring wird der scho wieder kleiner werden

                      Ist aber von der Übersicht nicht so problematisch find ich.

                      Kommentar


                      • #12
                        Zum Thema: Ich habe es ziemlich so gemacht, wie es im ersten Post beschrieben wird (Glaube ich zumindest). Mein Framework arbeitet nicht mit Modulen, Controllern und Actions, sondern alles ist ein HMVC-Knoten. Jeder Knoten ist quasi eine dedizierte Action. Würde bedeuten, wenn man z.B. einen Eintrag im Gästebuch bearbeiten wollte, wäre das etwa so:

                        domain.tld/guestbook.entry.edit/entry_id/xxx

                        Der Dispatcher wählt dann anhand von "guestbook.entry.edit" den entsprechenden Knoten aus. Der Vorteil dabei ist, dass
                        1. Mehr als 3 "Dimensionen" möglich sind (Modul/Controller/Action)
                        2. Das jeder Knoten - im Prinzip - an jeder Stelle eingebunden werden kann. So kann z. B. ein Kontaktformular sowohl als eigene Seite als auch als Bestandteil einer GUI eingebunden werden.

                        Das URL-Layout hängt natürlich vom Dispatcher ab. Die URL könnte auch so aussehen:

                        domain.tld/guestbook/entry/edit/-/entry_id/xxx

                        Kommentar


                        • #13
                          Nur aus reinem Interesse: Wann hat man denn mal mehr als drei Dimensionen? Man könnte sich natürliche schicke Namespaces zusammenbauen, aber je mehr Dimensionen man benutzt, desto "unhandlicher" werden auch dei URIs, oder irre ich da?

                          Ist bei dir "guestbook.entry.edit" jetzt ein Knoten oder eine Kette aus drei Knoten?

                          Kommentar


                          • #14
                            Das liegt natürlich im Auge des Betrachters, aber mir persönlich gefällt diese Unterteilung einfach besser. Ein - wenn auch etwas sehr konstruiertes - Beispiel wäre:
                            -> Benutzer -> Profil -> Gästebuch -> Eintrag -> Erstellen
                            Die URL dafür wäre nun z. B.

                            domain.tld/User.Profile.Guestbook.Entry.Create/user/xxx order auch lokalisiert
                            domain.tld/Benutzer.Profil.Gaestebuch.Eintrag.Erstellen/user/xxx oder auch
                            domain.tld/Benutzer/Profil/Gaestebuch/Eintrag/Erstellen/-/user/xxx

                            Das ist allerdings natürlich ziemlich sperrig, daher gibt es die Möglichkeit, die HMVC-Knoten zu "mappen". Das könnte dann so aussehen
                            domain.tld/create-guestbook-entry/user/xxx oder eben
                            domain.tld/gaestebucheintrag-erstellen/user/xxx

                            Ist bei dir "guestbook.entry.edit" jetzt ein Knoten oder eine Kette aus drei Knoten?
                            Nein -> Diese URL führt letztendlich dazu dass ein HMVC-Knoten Namens App_Guestbook_Entry_Edit aufgerufen wird - Wie bei MVC. Dort rufst Du ja auch immer eine feste Action auf.

                            Kommentar


                            • #15
                              OT
                              @xm22
                              Du schreibst "dein Framework....".
                              Darf ich fragen ob du ein selbst programmiertes oder ein fertiges benutzt?
                              Der Ansatz gefällt mir nämlich
                              Hilfe, mein Ball ist umgekippt!

                              Kommentar

                              Lädt...
                              X