Sollte der Controller über View & Model Bescheid wissen? oder umgekehrt?


13

Ich versuche konzeptionell zu verstehen, ob ich das tun sollte:

item = Model()
screen = View()
brain = Controller(item, screen)

oder dieses..

brain = Controller()
item = Model(brain)
screen = View(brain)

oder dieses..

class Controller():
    def __init__(self):
        item = Model(self)
        screen = View(self)

oder was ganz anderes?

Antworten:


18

Für mich macht die erste Option Sinn. Die Aufgabe des Controllers ist es, die Ansicht und das Modell zu koordinieren. Unter diesem Gesichtspunkt ist es sinnvoll, dass der Controller die Referenzen auf die Ansicht und das Modell steuert.

Ohne ein Modell und eine Ansicht kann es keinen Controller geben. Es ist jedoch viel sinnvoller, nur eine Ansicht oder nur ein Modell zu haben (z. B. beim Komponententest). Aus diesem Grund möchten Sie diese Abhängigkeiten an den Controller übergeben und nicht an die beiden anderen.


9

Die Modelund Viewsind voneinander unabhängig.

Denken Sie nicht an Controllerdie Köpfe der MVC-Struktur. Stellen Sie sich das als den Dispatcher vor, der die Anforderungen vom Browser verarbeitet und sie an den Dispatcher weiterleitet Model. Es entnimmt die Daten aus dem Modelund verpackt sie auf vorlagenfreundliche Weise und sendet sie dann an a View.

Das Modelist das Gehirn in der MVC-Struktur, und hier sollten Sie Ihre Geschäftsregeln einfügen. Geschäftsregeln sind häufig über mehrere Controller . Ein Dokumentcontroller und ein Berichtcontroller können also beide ein Benutzermodell verwenden, um zu sehen, wer Zugriff auf diese Dinge hat. Sie möchten diese Regeln nicht in beiden Controllern wiederholen.

Sie Viewsollten eine HTML-Vorlage verwenden, um die Daten nicht quellenspezifisch darzustellen. Es sollte nicht eng an das Schema Ihrer Datenbank gebunden sein. Um den Titel eines Dokuments anzuzeigen, müsste die Ansicht den Inhalt einer aufgerufenen Vorlagenvariablen ausgeben document_title, und nur der Controllerweiß, wie diese Variable festgelegt wurde, und nur der Modelweiß, warum dieses Dokument diesen Titel hat.


1
Ich mag Ihre Antwort, da sie mit meinem allgemeinen Verständnis von MVC verschmilzt. Es wird jedoch kein wichtiger Teil der Frage angesprochen, insbesondere welche Teile der Triade verweisen auf die anderen? Die Verwirrung, die ich denke, rührt von der Tatsache her, dass Sie beschreiben, dass Ansichten "dumme Vorlagen mit Löchern" sind (dh keinen Verweis auf den Controller enthalten, aber der Controller die Ansichten kennt und Daten aus dem Modell in sie einfügt). Gleichzeitig sehe ich immer wieder, dass Ansichten Benutzeraktionen an den Controller senden sollten. Wie könnte Views dies tun, ohne einen Verweis auf C zu haben?
Alnafie

@alnafie Sie haben das MVC-Framework in nur 3 Klassen vereinfacht. Schauen Sie sich in vorhandenen MVC Open Source-Frameworks um, und Sie werden feststellen, dass viel mehr erforderlich ist, damit es funktioniert. Es muss etwas Höheres geben, das alle Teile für das Framework verwaltet. Etwas, das die Controller aufruft, und etwas, das das Routing zu Aktionen in den Ansichten übernimmt.
Reactgular

3

MVC wurde ursprünglich definiert, um die Programmierung von Desktop-Anwendungen zu vereinfachen. Die Ansicht hat Modellereignisse abonniert und aktualisiert die Präsentation, wenn sich das Modell ändert. Der Controller übersetzte lediglich Ereignisse der Benutzeroberfläche (z. B. einen Tastendruck) in Aufrufe des Modells. Der Controller und die Ansicht hingen also vom Modell ab, waren jedoch voneinander unabhängig. Das Modell war von beiden unabhängig. Dadurch konnten mehrere Ansichten und Controller auf demselben Modell arbeiten.

Die für Web 1.0-Anwendungen verwendete "MVC" -Architektur (vollständige Seitenaktualisierung, kein AJAX) ist etwas anders. Eine Webanforderung wird an einen Controller gesendet. Der Controller ändert irgendwie den Modellstatus und sendet dann ein oder mehrere Modelle, die von einer Ansicht gerendert werden sollen. Der Controller und die Ansicht hängen beide vom Modell ab, aber der Controller hängt auch von der Ansicht ab.

Mit den Web 2.0-Anwendungen kehren wir auf der Client-Seite zur klassischen MVC-Architektur zurück . Das Modell, die Ansicht und der Controller befinden sich alle auf der Clientseite als Javascript-Objekte. Der Controller übersetzt Benutzerereignisse in Modellaktionen. Die Modellaktionen können zu einer AJAX-Anforderung an den Server führen oder nicht. Auch hier abonniert die Ansicht Modellereignisse und aktualisiert die Präsentation entsprechend.


+1 gute Antwort. Ich kann Modell-Callbacks für Desktop-Anwendungen im klassischen Sinne verstehen. Erinnert mich an alte MFC von Microsoft.
Reactgular

2

Die Ansicht sollte Änderungen im Modell abonnieren. Der Umfang der Abonnements ist unterschiedlich, da sie detailliert (Änderungen des Inventars für diesen bestimmten Artikel anzeigen) oder allgemein (das Modell hat sich geändert) sein können. Die Ansicht kann das Modell als Antwort auf eine Änderungsbenachrichtigung abfragen. Die Ansicht zeigt die gewünschten Modellelemente auf dem Bildschirm an und aktualisiert den Bildschirm wie bei der Bearbeitung von Änderungsmeldungen.

Der Controller sollte aufgrund der Benutzeranweisung Änderungen am Modell vornehmen (z. B. Tastatureingaben, Maus- und Menübefehle).

Das Modell verwaltet das Modell und eine Liste von Abonnements und sollte Ansichten über anwendbare Änderungen über deren Abonnements benachrichtigen.

Es muss auch einen Mechanismus zum Erstellen neuer Ansichten und Controller geben (da in MVC zwei oder mehr Ansichten desselben Modells vorhanden sein sollten (dies können die gleichen Ansichten (Punkte) oder verschiedene Ansichten (Punkte) sein). Logischerweise können wir davon ausgehen, dass der Controller eine View & Controller (Pair) -Factory ausführen muss oder Zugriff darauf hat, die Teil des Controllers oder einer anderen Komponente sein kann.


-1 Modelsnicht benachrichtigen Views. ControllersFragen Sie Modelnach Änderungen und rendern Sie dann, Viewsum diese Änderungen zu präsentieren.
Reactgular

4
@MathewFoscarini in MVC abonniert die Ansicht Änderungen des Modells. Siehe zum Beispiel wiki.squeak.org/squeak/598 .

Ich denke, wir sprechen nicht über Unterschiede in einem bestehenden MVC-Framework. Zend MVC, C # .NET und CakePHP verbinden kein Modell mit der Ansicht. Eine Ansicht in diesen Frameworks ist unabhängig. Ich weiß nicht, mit welchem ​​MVC Sie gearbeitet haben, aber ich würde es als nicht traditionell bezeichnen.
Reactgular

6
@MathewFoscarini: Dies sind alles Web-Frameworks, und obwohl sie sich "MVC" nennen, folgen sie nicht der klassischen MVC-Architektur.
Kevin Cline

2
Ich bin mir nicht sicher, ob eine MVC "traditioneller" ist als eine Smalltalk-MVC, da dies die erste ist, in der das Muster beschrieben wurde.

1

MVC ist eher ein Modularitätsmuster. Der Zweck besteht darin, dass Sie bei jeder Änderung des Layouts der Benutzeroberfläche (Ansicht) weder die Anwendungslogik (Controller) noch die internen Datenverarbeitungen (Modell) ändern müssen.

Um dies zu erreichen, besteht das Muster darin, die Implementierungslogik jeder MVC-Komponente zu isolieren. Dennoch ist es völlig normal , dass es Komponenten der jeweils anderen kennen Schnittstellen .

Was ich oft gesehen habe, ist, dass der Controller ein Modell und eine Ansicht erstellt oder aufruft (daher kennt er deren Benutzeroberfläche) und dass das Modell oder die Ansicht den Controller als Gegenleistung benachrichtigen kann (eher wie ein Rückruf oder ein Beobachtermuster). Der wichtige Teil ist, dass der Controller die Layoutstruktur nicht kennt.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.