MVC Konzept

[Cogax]

Guten Abend allerseits..

Seit längerer Zeit setze ich mich mit dem MVC Konzept auseinander. Was ich anfänglich überhaupt nicht peilte wird mir so langsam aber sicher immer klarer. Mir ist bewusst dass es nicht eine einzige Lösung gibt, sondern jeder seine eigene finden muss.

Desshalb habe ich meine MVC Vorstellung mal möglichst kurz und knapp versucht zu erfassen:
http://g02i.img-up.net/MVC-NewPag0a04.jpeg?l=de

index.php

$_GET['action'] = 'editPerson';
$controller = new Personenverwaltung($_GET['action']);
echo $controller->getView(); 

Im Konstruktor des Controllers ein Switch-Konstrukt ausgeführt, welches action-spezifisch eine private Methode des Controllers aufruft: formEditPerson() zum Beispiel.

In der View-Klasse greifen die Getters und Setters auf das $vars-Array zu. Gibts evtl. bessere Lösungen?

Eine weitere Unsicherheit ist der PersonenGrupperHandler. Ein Model ist dies meiner definition nach nicht. Hier würde ich im Controller die MySQL befehle für die zuweisungen ausführen lassen.


Nun, ich hoffe Ihr könnt mir helfen, wie ich mein MVC Konzept noch verbessern kann. Dies wäre meine Lösung wenn ich hier und heute ein MVC Projekt umsetzen müsste, ich bin jedoch nicht in der Lage Schwachpunkte zu finden bei einem allfälligen Praxiseinsatz.

[tr0y]

Controller sollten nicht mit views um sich werfen sondern mit einem Response. mach deine Actions öffentlich, damit jede einzelne action als rückgabewert eine Response ausliefern kann ( besser muss ) und von einer Dispatch-Mechanik aufgerufen werden kann. Controller sollten nicht magisch beim erstellen schon die action aufrufen, die sie selbst auch noch feststellen müssen, das ist Aufgabe des Routings.

[Cogax]

Danke für die Antwort.

Was verstehst du unter "Response", wie soll der deiner Meinung nach aussehen? Sind denn die Actions nicht öffentlich?

Controller

Der Browser akzeptiert Formulareingaben und sendet diese ab oder nimmt das Anklicken eines Links entgegen. In beiden Fällen sendet er einen HTTP-Request an den Server. Der Controller-Programmteil verarbeitet die Daten der HTTP-Requests und stößt schließlich die Erstellung eines neuen Views an.

Wikipedia

Edit: Das "Routing" würde ich so machen: https://github.com/Cogax/BST/blob/ma...pplication.php bzw. https://github.com/Cogax/BST/blob/ma...estHandler.php

[BlackScorp]

ein Response besteht aus Body und Header informationen, im Body steht meist ein Text und der Header definiert dann wie der client es verarbeiten soll, content-type setzen, content disposition usw.. das ist ein Response, eine antwort.

Deine Seite generiert eine Request klasse mit $_SERVER informationen usw.. Request klasse wird an router übergeben, der router schaut anhand der URL welcher controller und action aufgerufen werden soll, wenn der router den passenden controller gefunden hat, wird die request klasse an die action mit übergeben, so dass du die parameter aus der request klasse holen kannst. danach lädste in der action das notwendige model und machst irgendwas damit, erzeugst weitere klassen und generierst mit hilfe von templates ein HTML body, diesen übergibste an die Response klasse..

am ende schreibste einfach echo $response->body() und davor setzt du mit header funktion die $response header informationen..

so einfach ist das

[borgas]

Hier würde ich im Controller die MySQL befehle für die zuweisungen ausführen lassen.

Die sql-befehle stehen ausschließlich im Model. Abgesehen davon glaube ich, dass du dich noch nicht mit Themen wie Routing o.ä. auseinandergesetzt hast. Ein Pattern ist dazu da die Wartbarkeit eines Programmes zu verbessern, aber wenn du um jeden Preis ein Pattern einsetzt und dieses falsch umsetzt, kannst du auch darauf verzichten. Also: Entweder komplett daran halten, oder gar nicht einsetzen.

[litterauspirna]

Die sql-befehle stehen ausschließlich im Model.

Selbst das ist nicht ganz richtig, solche Anweisungen sollten im DAO / Repostitory stehen. Ein Model sollte eigentlich ausschließlich nur die Daten zurückgeben bzw. rückspiegeln (mir fällt grad der richtige Ausdruck dafür nicht ein).

[tr0y]

Bereitstellen.

[litterauspirna]

Bereitstellen.

So einfach kann das sein