Ankündigung

Einklappen
Keine Ankündigung bisher.

MVC für die Tonne

Einklappen

Neue Werbung 2019

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

  • MVC für die Tonne

    Hallo,

    ich bin gerade dabei Frameworks auszuprobieren, weil das ZF2 bei einem Prototyp hier sehr langsam ist. 250ms für eine leere Controller-Action + leeren View sind einfach zuviel.

    Jetzt habe ich mir mal das Slim-Framework angeschaut und das ist recht simpel. Ich mappe eine Route auf ein Closure.
    PHP-Code:
    <?php
    $application
    ->get('/project', function() {
      echo 
    "project list";
    });
    Ist nur ein Beispiel, aber so ungefähr. Mit View und ServiceManager eigentlich ganz nette Idee.

    Also eigentlich genau das, was ich immer haben wollte. Nur dass ich kein Closure will, sondern eine fixe Klasse. Eine Route = eine Action = eine Klasse.

    PHP-Code:
    <?php
    $application
    ->get('/project', array(
      
    'invokable' => 'JarJar\Project\ListAction'
    ));
    Das jetzt noch in eine Konfiguration ausgelagert:
    PHP-Code:
    <?php
    array(
      
    'router' => array(
        
    'routes' => array(
          
    'project/list' => array(
            
    'route' => '/project',
            
    'type' => 'literal',
            
    'action' => 'projectListAction'
          
    )
        )
      ),
      
    'service' => array(
        
    'invokables' => array(
          
    'projectListAction' => 'JarJar\Project\ListAction'
        
    )
      )
    );
    ?>
    Warum wird das allgemein immer noch mit Controllern und Action-Methoden gehandlet? Wenn man dem Prinzip folgt, eine Klasse = eine Aufgabe, also die Änderung einer Klasse sollte nur aus einem einzigen Grund erlaubt sein, dann ist das Konzept Controller-Actions doch schon kaputt, oder? Ganz abgesehen davon, dass ich Code soweit dupliziere, weil er für die meisten Entitäten ja gleich ist: Laden, Speichern, Löschen. Formularverarbeitung, Rechte verwalten, bla.

    Ich hab jetzt mal kurz ein Micro-Framework geschrieben, das anhand einer Config Routen auf Action-Klassen mappt (siehe oben Ausschnitt-Beispiel). Wenn man jetzt noch konfiguriert, welche Art von Action es ist (view => mappt Model-Daten in den View; edit = mappt Model-Daten in ein Formular und das Formular in den View; ..) kann man sich doch fast die gesamte Programmierarbeit sparen und schnell ist es ohne den ganzen ZF2-Overhead Firlefanz auch. Diese ganze Adapter-Scheisse nervt mich eh, ich benutz eine einzige Datenbank, hab außer 1x nie den Datenbanktyp geändert. Diese abstrahierten Frameworks produzieren Unmengen an Overhead um Features zu bieten, die am Ende keiner braucht.

    Meine Frage ist jetzt tatsächlich:

    * Wozu gibt es Controller-Klassen und Action-Methoden, warum mappt man einen Request nicht auf eine Action-Klasse?
    * Ist die Idee von mir so neu oder so schlecht, dass ich im Internet dafür nichts finden kann?


    Außerdem benötige ich für meine Anwendung mehrere Actions pro Aufruf, da die "Sidebar" auch recht komplex sein wird. Auch das scheint immer nur halbherzig umgesetzt zu sein. Zugegeben altes Problem.

    Bei meinem Mini-Micro-Framework (Application + Router + ServiceManager) mappt der Router eine Route auf eine Action-Klasse. Die kann sich per ServiceManager holen was sie braucht. An der Action hängt ein View und vielleicht auch ein Layout. Das Layout selbst kann nun noch mehr Actions beinhalten (Footer, Sidebar, Navigation). Sprich am Ende habe ich einen ActionTree (und damit auch einen ViewTree). Aber ich finde das eigentlich logisch, denn wenn ich die Action ohne Layout lade (z.B. per XHR) brauche ich ja auch die Sidebar-Action nicht. Daher der Weg über das Layout weitere Actions zu identifizieren. Trotzdem kommt es mir unkonventionell vor, wenn ein Layout eine Action laden kann. Naja.

    Beim ZF2 scheint es mir nicht ohne Brumbrum möglich, mehrere Actions "auf natürliche Weise" abzuarbeiten. Ich muss dann entweder in jeder Action, die eine Sidebar hat, nochmal "irgendwas" (Controller-Plugin o.ä.) aufrufen, das die Sidebar konfiguriert oder die Konfiguration im View-Helper machen. Damit ist dann gefühlt meine Controller-Action für den Arsch, weil ich noch x Bedingungen einbauen muss, dass z.B. bei einem AJAX-Request die Sidebar doch nicht konfiguriert wird.

    Bei meinem Mini-Micro-Framework würde bei AJAX eben das Layout deaktiviert und damit auch die Sidebar wegfallen. Die Idee gefällt mir, ich bin nur nicht sicher ob die Idee wirklich gut ist und ich frag mich, warum das bei bisherigen Frameworks nur so kompliziert möglich ist.

    Danke & Gruß,
    Chriz
    "Mein Name ist Lohse, ich kaufe hier ein."


  • #2
    TL;DR
    PHP ist kein Natural-Fit für MVC. http://paul-m-jones.com/archives/6020
    > https://github.com/pmjones/mvc-refinement

    Das was du beschreibst ist beispielsweise einer der Gründe, warum ich bislang nicht mit Zend und Symfony warm geworden bin. Ich will nicht abstreiten, dass man solche Szenarien damit auch lösen kann.
    Standards - Best Practices - AwesomePHP - Guideline für WebApps

    Kommentar


    • #3
      Ich mach das Ständig, ich nutze Silex framework, mappe meine Routen zu controllern + bestimme noch zusätzlich das verhalten der routen.

      https://github.com/Opentribes/Core/b...me.php#L56-L63

      hier zb was soll passieren wenn controller nicht fehlschlägt?

      oder hier https://github.com/Opentribes/Core/b...r/Game.php#L39 route ist an ein controller und ein view gebunden , controller liefert ein POPO Response und dieses wird blind mit dem template geparst(d.h. ich muss mich schon vorher drum kümmern welche variablen im response stehen)

      zu deiner frage
      * Ist die Idee von mir so neu oder so schlecht, dass ich im Internet dafür nichts finden kann?
      Die idee gibt es schon länger, ich klinge jetzt vielleicht wie ein verschöwrungstheoretiker aber Zend, Symfony und Co haben das ja damals gemacht weil keine ahnung, auf jeden fall gibt es ja Framework Zertifikate usw usw, will sagen, aus Architektonischer sicht ist MVC nicht so schön(wie du es ja gemerkt hast) aber aus kommerzieller sicht wird das noch so weiter extestieren

      auch neue frameworks verwenden ja die begrifflichkeiten damit andere es verstehen
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

      Kommentar


      • #4
        Nein, das hat nichts mit Verschwörungstheorien zu tun, das wird auch in MVC in anderen Sprachen gemacht (wie Java oder C#). Dort ist ein Controller auch in mehreren Actions verteilt, ganz einfach. In Java ist es üblich für einen Controller ein Interface zu haben, das definiert, was gemacht werden muss. Das wurde wahrscheinlich einfach nur als Konzept übernommen in PHP. Finde ich persönlich auch nicht schlecht.
        Crashkurs zum Thema Rechtschreibung: normalerweise (normaler weise oder normaler weiße), Standard (Standart), eben (ebend)

        Kommentar


        • #5
          @Chriz: Jetzt habe ich den Beitrag von dir ganz gelesen. Das was du beschreibst, mache ich schon seit Jahren in verschiedenen Projekten so. Mit einer Ausnahme: Ich binde keine Closures an Routen, sondern einfache Arrays mit Parametern. In den Parametern wird beschrieben, "was" "wie" aufgerufen und wie mit dem Ergebnis umgegangen werden soll.

          Heisst, eine Route könnte lauten "mit mir rufst du Klasse X und Methode Y und das Ergebnis gibst du als JSON aus". Alternativ kann das Ergebnis auch an eine Template-Engine weitergereicht werden, die dann beispielsweise HTML erzeugt.

          Der Ansatz von BlackScorp scheint sehr ähnlich zu sein.
          Standards - Best Practices - AwesomePHP - Guideline für WebApps

          Kommentar


          • #6
            In Laravel hast du die Möglichkeit einen Controller und eine Methode - aus dem Controller - an eine Route zu binden.

            Dir ist überlassen ob du jetzt für eine /user/create Route den Controller User und die Methode create definierst oder doch lieber den Controller CreateUser und die Methode execute!

            Bei der zweiten Variante hättest du doch deine Action Klassen!

            Kommentar


            • #7
              Zitat von Asterixus Beitrag anzeigen
              In Java ist es üblich für einen Controller ein Interface zu haben, das definiert, was gemacht werden muss.
              Das kenne ich in Java für Services, DAOs und Models, aber nicht für Controller, da die in der Regel nicht ausgetauscht werden müssen / sollen.

              Also zumindest wenn man da mit Spring / Jersey etc. arbeitet ist mir das noch nie unter gekommen.
              Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
              http://www.lit-web.de

              Kommentar


              • #8
                Hi,

                danke euch, die Links haben extrem geholfen. Ich arbeit mich jetzt mal tiefer ein.
                "Mein Name ist Lohse, ich kaufe hier ein."

                Kommentar


                • #9
                  Gerade Microframeworks basieren nativ auf Action-Callbacks statt auf Controller die Action-Methoden haben. Im hinterkopf sollte man behalten das man Grundsätzlich Controller nutzt um Actions zu gruppieren.

                  Würdest du eine Controller-Action in einer Klasse kapseln wärst du bei diesem Minimal:

                  PHP-Code:
                  class FooAction {

                     public function 
                  __construct(...$services)
                     {
                        
                  /* ... */
                     
                  }

                     public function 
                  __invoke(...$requestItems)
                     {
                        
                  /* ... */
                        
                  return Response::create($response200'text/html');
                     }


                  Was ja Grundsätzlich nicht gegen das MVC-Prinzip verstößt und ein PHP 5.4 Äquivalent zu einem verbundenen Closure als Route Action darstellt.
                  [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                  Kommentar


                  • #10
                    Naja, mit einer Controller-Klasse kann man eher von CodeReuse und (im Falle der Closure-Taktik) Autoloading profitieren.
                    Standards - Best Practices - AwesomePHP - Guideline für WebApps

                    Kommentar

                    Lädt...
                    X