MVC - Es ist falsch, vom Modell umzuleiten

Weder Controller noch Modell sollten irgendwo etwas umleiten. HTTP-Location-Header ist eine Form einer Antwort, die ausschließlich im Blickwinkel der Ansichten.

Model-Layer beschäftigt sich mit Business-Logik, sollte es sogar für die Existenz der Präsentationsschicht völlig blind sein.

Grundsätzlich geht es darum: Controller handhaben Eingaben, Ansichten handhaben Ausgabe . HTTP-Header sind Teil der Ausgabe.

  

_{Hinweis: Beim Umgang mit Rails-Klonen werden häufig Weiterleitungen in "controller" ausgeführt. Es ist, weil das, was sie "Controller" nennen, eigentlich eine Verschmelzung von View- und Controller-Verantwortlichkeiten ist. Dies ist ein Nebeneffekt der Entscheidung, echte Ansichten durch einfache Vorlagen als dritte Seite der Dreiergruppe zu ersetzen.}

Am häufigsten in Webapplikationen - MVC oder nicht - werden Redirects auf einer höheren Ebene implementiert. In nicht-OOP-Code ist dies oft eine globale Funktion auf hoher Ebene, die viel über den globalen statischen Zustand weiß und was eine Anfrage und eine Antwort darin repräsentiert.

In mehr OOP-getriebenen Sites finden Sie dies oft als eine Methode mit dem "response" -Objekt (vergleiche Symfony2 und HTTP Fundamentals ; beachten Sie, dass Symfony2 nicht MVC ist), es hat jedoch oft auch ähnliche Methoden (zB Unterschied zwischen $this->render und $this->redirect Symfony2 ).

Da diese "Antwort" -Objekte meistens in der Web-Anwendung eine zentrale Rolle spielen, ist dies in meinen Augen ebenso möglich wie eine höhere Ebene.

Aus Testsicht - insbesondere bei Integrationstests - müssen Sie normalerweise nicht speziell auf Weiterleitungen testen. Sie sollten testen, dass in der Regel Ihre Redirect-Funktionalität auf der HTTP-Ebene funktioniert, so dass Teile Ihrer Anwendung, die davon Gebrauch machen, darauf vertrauen können. Häufige Probleme sind, den Vorschlägen in den HTTP / 1.1-Spezifikationen nicht wirklich zu folgen, wie etwa die Bereitstellung eines Antwortkörpers mit Weiterleitungen. Eine gut funktionierende Webanwendung sollte dies berücksichtigen. Dies gilt auch für die Verwendung von vollständig qualifizierten URIs.

Wie passt das alles hier in MVC? In einem HTTP-Kontext könnte dies wie folgt vereinfacht werden:

• Die Antwort besteht darin, dem Benutzer mitzuteilen, dass er woanders hingehen soll.
• Wenn der Benutzer nicht wichtig wäre, könnte die Anwendung forward direkt - das ist ein anderer Befehl ausführen, der Client würde nicht dafür verwendet werden, die Umleitung nicht notwendig (Unterbefehl).
• Die Antwort lautet: Erledigt. Und dann: Siehe als nächstes diesen Befehl (in Form eines URI).

Das hört sich ziemlich so an, als wäre die tatsächliche Weiterleitung nur eine Ausgabe, die Sie in der Client-Kommunikation auf Protokollebene an den Client senden. Es gehört in die Schnittstelle des Protokolls, das Sie unterstützen möchten. Also nicht in das Modell, sondern in die Client-Schnittstelle und die Grenze der Client-Schnittstelle innerhalb einer MVC-Anwendung ist der Controller AFAIK.

Also ist die Weiterleitung wahrscheinlich ein View-Value-Objekt mit einer besonderen Bedeutung. Um das in einem HTTP-MVC zu erreichen, benötigen Sie eine vollständige URL-Abstraktion, die die meisten PHP-Frameworks und -Bibliotheken groß machen, weil es nicht gut bekannt ist, wie das funktioniert. Also würde ich am Ende sagen: Tun Sie, wie Symfony2 es getan hat, legen Sie es in eine Layer-Komponente auf hoher Ebene, lassen Sie MVC fallen und leben Sie mit den Mängeln.

Alles andere ist schwer zu erreichen, wenn Sie es anders versuchen, besteht ein hohes Risiko, nicht mehr mit dem Abstrahieren aufzuhören.

Ich würde ja sagen, es ist falsch. Soweit ich verstanden habe, sind die Controller während der Verwaltung von Daten und Ansichten für die Verwaltung von Layouts (dh wie Daten angezeigt werden sollen) für die HTTP-Anfragen / -Antworten nur und ausschließlich zuständig Management (im Falle einer Web-App), und Umleitungen gehören meiner Meinung nach normalerweise zu dieser Ebene.