Ich bin mir bewusst, dass ich eine sehr alte Frage beantworte, jedoch glaube ich nicht, dass eine andere Frage Ihr ursprüngliches Anliegen angemessen beantwortet hat, und hoffentlich wird dies etwas Nützliches für andere hinzufügen, die auf diese Frage stoßen könnten, während sie sich über MVC informieren.
Zunächst einmal möchte ich sagen, dass ich einen interessanten Artikel über die Verwirrung gelesen habe, die innerhalb der PHP-Community über MVC besteht, und es lohnt sich, ihn zu lesen, wenn Sie diese Art von Frage stellen.
Model-View-Verwirrung Teil 1: Die Ansicht erhält ihre eigenen Daten aus dem Modell
Zweitens glaube ich nicht, dass Sie etwas falsch verstanden haben, sondern ein besseres Verständnis von PHP und MVC haben, das es Ihnen ermöglicht, die Frage zu stellen. Nur weil etwas von der Gemeinschaft definiert und akzeptiert wurde, bedeutet das nicht, dass Sie die Verwendung nicht von Zeit zu Zeit in Frage stellen sollten. Und hier ist der Grund.
Es gibt KEIN Gedächtnis zwischen Anfragen (außer für die SESSION-Sitzung) innerhalb einer PHP-Anwendung. Jedes Mal, wenn eine Anfrage empfangen wird, startet die gesamte Anwendung, bearbeitet die Anfrage und wird dann wieder heruntergefahren, d. h. es gibt keine im Hintergrund laufenden Anwendungsthreads (zumindest keine, die Sie in Ihrer Anwendung verwenden können), in denen Sie theoretisch den Anwendungsstatus beibehalten könnten. Das ist weder gut noch schlecht, es ist einfach so.
Wenn Sie das verstehen, können Sie wahrscheinlich erkennen, dass Ihre Gedanken korrekt sind. Warum würde eine Ansicht (die berechtigt ist, ihre eigenen Daten aus dem Modell abzurufen) einen Controller benötigen? Die einfache Antwort ist, dass sie das nicht muss. Für die reine Anzeige eines Modells ist es völlig legitim, dass die Ansicht ihre eigenen Daten abruft (über das Modell), und tatsächlich ist dies der richtige Weg zur Implementierung von MVC.
Aber Moment mal. Bedeutet das, dass wir keine Controller benötigen? Absolut NICHT! Was wir tun müssen, ist einen Controller für seinen angemessenen Zweck zu verwenden. Im MVC ist der Controller dafür verantwortlich, Benutzeranfragen zu interpretieren und das Modell zu bitten, sich zu ändern, um der Benutzeranfrage gerecht zu werden, danach kann das Modell seine Abhängigkeiten über die Änderung informieren und die Ansicht kann sich aktualisieren. Offensichtlich, wie Sie wissen, sitzt die Ansicht in einem PHP-Webanwendungs-Kontext nicht nur da und wartet auf Aktualisierungsmeldungen. Wie können Sie also die Benachrichtigung erreichen?
Hier glaube ich, wurde MVC gekapert. Um der Ansicht mitzuteilen, dass sich ihr Modell geändert hat, können wir sie einfach zur URL der Ansicht leiten, die auf das aktualisierte Modell zugreift. Großartig, aber jetzt haben wir etwas in den Controller eingeführt. Etwas, das sagt: "Hey, ich bin ein Controller, aber jetzt kenne ich den Standort der Ansicht." Ich denke, zu diesem Zeitpunkt dachte jemand: "Warum sollte ich den Benutzer umleiten? Ich habe alle Daten, die die Ansicht benötigt, warum sollte ich die Daten nicht einfach direkt an die Ansicht senden?" und zack! Hier sind wir.
Lassen Sie uns also zusammenfassen.
- Eine Ansicht kann im Rahmen von MVC direkt auf das Modell zugreifen
- Das Modell enthält die Geschäftslogik für die Domänenobjekte
- Ein Controller soll der Ansicht keinen Zugriff auf das Modell gewähren oder als eine Art Vermittler fungieren
- Der Controller akzeptiert Benutzeranfragen und ändert sein Modell
- Eine Ansicht ist nicht die Benutzeroberfläche/HTML, dafür wird eine Vorlage verwendet
Ein praktisches Beispiel Um zu erklären, was ich beschrieben habe, werden wir uns eine einfache, häufig vorkommende Funktion auf den meisten Websites heute ansehen. Das Anzeigen der Informationen eines einzelnen angemeldeten Benutzers. Wir lassen viele Dinge aus unserem Code hier aus, um nur die Struktur des MVC-Ansatzes zu demonstrieren.
Angenommen, wir haben ein System, bei dem eine GET-Anfrage für /user/51 auf unsere UserView mit den entsprechenden Abhängigkeiten gemappt wird.
Definieren wir also unsere Klassen.
// UserModel.php
class UserModel {
private $db;
public function __construct(DB $db) {
$this->db = $db;
}
public function findById($id) {
return $this->db->findById("user", $id);
}
}
// UserView.php
class UserView {
private $model;
private $template;
private $userId;
public function __construct(UserModel $model, Template $template) {
$this->model = $model;
$this->template = $template;
}
public function setUserId($userId) {
$this->userId = $userId;
}
public function render() {
$this->template->provide("user", $this->model->findById($this->userId));
return $this->template->render();
}
}
Und das ist es! Sie benötigen den Controller überhaupt nicht. Wenn Sie jedoch Änderungen am Modell vornehmen müssen, würden Sie dies über einen Controller tun. Das ist MVC.
Haftungsausschluss
Ich befürworte nicht, dass dieser Ansatz korrekt ist, und jeder Ansatz, den ein Entwickler zu einem bestimmten Zeitpunkt verfolgt, ist falsch. Ich glaube fest daran, dass die Architektur eines Systems seinen Bedürfnissen entsprechen sollte und nicht einem bestimmten Stil oder Ansatz, wenn es notwendig ist. Alles, was ich zu erklären versuche, ist, dass innerhalb von MVC eine Ansicht tatsächlich berechtigt ist, direkt auf ihre eigenen Daten zuzugreifen, und der Zweck eines Controllers besteht nicht darin, zwischen Ansicht und Modell zu vermitteln, sondern er soll Benutzeranfragen akzeptieren, die eine Manipulation eines bestimmten Modells erfordern, und das Modell auffordern, solche Operationen durchzuführen.
2 Stimmen
Es heißt Model View Controller (MVC). Das bedeutet, dass du einen Controller brauchst.
1 Stimmen
@sockeqwe, hast du die "richtige Antwort" aufgrund der Länge gewählt? Denn die aktuelle Antwort (von Scott Bailey) ist völlig falsch und völlig daneben.
0 Stimmen
@tereško, was würden Sie in Scotts Antwort ändern, entfernen oder hinzufügen?
1 Stimmen
Alle „Langtexte“, da sie alle falsch sind
0 Stimmen
Denkst du das? Was genau?