Fragen zu kleinen MVC-System (speziell Controller)

[Truncate]

Hallo,

ich spiele gerade mit dem MVC von "Lemme" rum.

Da sieht's im Controller z.B. so aus:

        public function display()
        
        {

            $view = new View();

            switch($this->template)
            
                {
                                
                    case 'impressum':
        
                        $view->setTemplate('impressum');
                        $this->title=" - Impressum";
                        break;
                    
                    case 'newsletter':
                    
                        $view->setTemplate('newsletter');
                        $this->title=" - Newsletter";
                        break;
                    
                    case 'newsletterdanke':
                    
                        $view->setTemplate('newsletterdanke');
                        
                        if(!empty($this->request['eMail']))
                        {$view->assign('message', 'Ihre eMail-Adresse '.$this->request['eMail'].' wurde hinzugefügt.');}
                        else
                        {$view->assign('message', 'Es wurden nicht alle Felder ausgefüllt!');}
                        break;
                    
                    case 'default':
                    default:
                    
                        $view->setTemplate('default');

                }

    
            $this->view->setTemplate('layout');
            $this->view->assign('projekt', 'Projektname');
            $this->view->assign('title', $this->title);
            $this->view->assign('content', $view->loadTemplate());

            return $this->view->loadTemplate();

        } 

Dazu ein paar Fragen:

1) Statt die Befehle direkt unter z.B. "impressum" zu schreiben, kann ich diese auch in "classes/impressum.controller.php" auslagern und dann lediglich includen? Ist das dann sozusagen ein "Modul"?

2) Die NewsletterDanke-Verarbeitung dient nur als profane Demo, würde man hier dann normalerweise sowas wie "Validator-Klassen" verwenden? Die gehören dann theoretisch auch in den Controller rein oder?

3) Ins Model kommen dann DB-Zugriff, DB-Funktionen und sonstige Daten (z.B. Arrays mit Versandkosten) rein?

Danke,
Truncate

[litterauspirna]

Hallo,

ich spiele gerade mit dem MVC von "Lemme" rum.

Dazu ein paar Fragen:

Das Lemme Tutorial finde ich ziemlich ungeeigent als Einstieg in MVC. Mich hatte das mal mehr verwirrt als alles andere.

1) Statt die Befehle direkt unter z.B. "impressum" zu schreiben, kann ich diese auch in "classes/impressum.controller.php" auslagern und dann lediglich includen? Ist das dann sozusagen ein "Modul"?

In der Regel übenehmen das Autoloader. Außerdem übernimmt das laden von Controllern und das Ausführen von Actions idr. ein Front Controller.
Welches View Template geladen werden soll, sollte eigentlich als Logik in der Controller Action passieren.
Man kann in diesem Fall nicht von einem Modul sprechen, zu modularer Entwicklung gehört weitaus mehr dazu.

2) Die NewsletterDanke-Verarbeitung dient nur als profane Demo, würde man hier dann normalerweise sowas wie "Validator-Klassen" verwenden? Die gehören dann theoretisch auch in den Controller rein oder?

Was ist in deinen Augen ein Validator? Normalerweise bringen z.B. Form Klassen ihre eigenen Validatoren mit. Wiederum können aber auch DAOS eigene Validatoren, wie zur Prüfung von Plausibilität enthalten.
Es kann aber auch durchaus in Controller Actions Validatoren geben, es kommt darauf an wo und aus welchem Grund ein Validator benutzt werden muss / soll.

3) Ins Model kommen dann DB-Zugriff, DB-Funktionen und sonstige Daten (z.B. Arrays mit Versandkosten) rein?

Um Himmels Willen nein, vollkommen daneben.

Ein Model ist ein Model, dass heißt es bildet einfach nur einen dummen Datencontainer ab, mehr nicht. Warum dumm? Ganz einfach, dass Model weiß nicht woher die Daten kommen, ob aus einer DB, XML, CVC, Excel Datei, JSON oder anderes.
Am besten sichert man jedes Model gegen ein Interface, so kann man Models sehr einfach austauschen. Models haben nur Properties, Setter und Getter Methoden.

Die CRUD (Create, Read, Update, Delete) Methoden gehören dann in ein Repository oder auch DAO genannt.

Der DB Zugriff / Identifikation muss schon viel eher passieren da bist du mit einem Model im MVC noch gar nicht in Berührung gekommen.
Das MVC ist nämlich nur in der Präsentationsschicht einer Anwendung angesiedelt (blöder Begriff, mir fällt grad kein besserer ein).
Um solche Sachen kümmert sich in der Regel eine Application Class.

Sind deine Fragen soweit beantwortet, oder hast du noch Verständnisprobleme, dann immer raus mit den Fragen.

Gruß der Litter

[Truncate]

Das Lemme Tutorial finde ich ziemlich ungeeigent als Einstieg in MVC. Mich hatte das mal mehr verwirrt als alles andere.

Ich hab auch noch einige andere Tutorials gefunden, nur erschlagen die einen eben gleich mit massig Klassen welche man nicht durchblickt.

Das Prinzip ist mit jedenfalls jetzt halbwegs klar:

.htaccess -> index.php -> Controller -> Requests auswerten

Die View speichert anscheinend nur die Ausgabe und läd die Templates, sonst nichts. Vermutlich müßte die View aber auch zusätzlich eine PDF-Ausgabe können etc.

Die Templates selbst sind "dumm", dort findet man also nur HTML und sonst kaum PHP-Befehle außer vielleicht echo() oder for().

Der Sinn des Models erschließt sich mir aber nach wie vor nicht. Kann man das z.B. an einem Gästebuch-Script erklären?

In der Regel übenehmen das Autoloader.

Also in der index.php oben schon einen Autoloader mit includen, das Impressum (Klasse) in classes/impressum.php auslagern und dann z.B.

case 'impressum':

$bla = Impressum::getDaten('telefonnummer'); 

?

Welches View Template geladen werden soll, sollte eigentlich als Logik in der Controller Action passieren.

Tut es das nicht schon im obigen Script?

Oder meinst Du den Verzicht bei jedem case auf das manuelle Zuweisen durch $view->setTemplate('impressum'); ?

Stattdessen gleich oben pauschal $view->setTemplate($this->template); ?

Das wäre doch aber unflexibel, wenn z.B. bei case 'newsletterdanke' die eMail falsch ist und statt dem Template 'newsletter' eben 'newsletterfehler' eingebunden werden soll.

Was ist in deinen Augen ein Validator? Normalerweise bringen z.B. Form Klassen ihre eigenen Validatoren mit.

Meinte das so:

if(Mail::Check($this->request['eMail'])==true){...} 

anstatt das alles direkt im Controller geprüft wird:

if(!empty($this->request['eMail'])){...} 

Ein Model ist ein Model, dass heißt es bildet einfach nur einen dummen Datencontainer ab, mehr nicht. Warum dumm? Ganz einfach, dass Model weiß nicht woher die Daten kommen, ob aus einer DB, XML, CVC, Excel Datei, JSON oder anderes.

Siehe oben: Das Model macht für mich keinen Sinn Ich würde einfach eine database.class.php laden und dann einfach Abfragen machen. Was für eine Rolle da noch extra das Model spielen soll, weiß ich nicht

Sind deine Fragen soweit beantwortet, oder hast du noch Verständnisprobleme, dann immer raus mit den Fragen.

Meine Fragen zum Thema PHP & MVC werden wohl nie versiegen

[litterauspirna]

Meine Fragen zum Thema PHP & MVC werden wohl nie versiegen

Nun genau liegt dein eigentliches Problem. Du versuchst MVC in PHP zu denken, warum? Das hat doch erst mal rein gar nichts mit PHP zu tun.

Du musst es im allgemeinen verstehen. MVC an sich ist vollkommen simpel. Ans eingemachte geht es bei dem was drum herum ist. Request, Response, Routing, Event und Hook System etcpp.

Warum macht ein Model keinen Sinn? Was hast du denn am Model nicht wirklich verstanden?

Aber mal kurz erklärt, ein Model ist im Prinzip eine dumme Klasse, welche einfach nur ein Datenmodell darstellt. Es verfügt über Properties sowie Getter und Setter Methoden, dass war es dann auch schon. Am besten sichert man seine Models noch gegen ein Interface, so kann man ganz bequem die Datenquelle von DB auf z.B. Json austauschen wenn es sein muss. Anwendungsbeispiel wäre ein Importer für json zu DB.

Die Logiken, z.B. Plausibilitätslogiken würden dann in eine sogenanntes DAO (Data Access Model), oder manche nennen es auch Repository kommen.

Und wenn man es noch besser haben will, verpackt man das ganze noch schön in einen Service.

Mehr gibt es dazu eigentlich nicht zu sagen.

Egal welches Design - Pattern man einsetzen will, man darf da nie in einer Programmiersprache denken sondern rein in OOP bzw. OOD und dann bekommt alles egal in welcher OOP unterstützenden Sprache unter.

Gruß Litter