Mit MVC, wie sollte man die Kommunikation zwischen Ansichten handhaben? Zwischen Modellen?

Question

Frage Nummer drei in meinem Bestreben zu verstehen, um richtig MVC vor ich es umsetzen:

ich zwei Fälle im Sinn haben:

1. Die primäre Anwendung Fenster braucht das Einstellungsfenster zu starten. (Eine Ansicht ruft eine andere Ansicht auf.)
2. Das primäre Modell für eine Anwendung muss im Präferenzmodell auf eine Eigenschaft zugreifen. (Ein Modell Zugriff auf ein anderes Modell.)

sind in diesen Fragen zusammen, dass sie beide Kommunikation beinhalten über Model-View-Controller-Drillinge, ein Thema, das ich nicht viel Diskussion in meinem googeln gefunden haben.

Der offensichtliche Weg, dies zu beheben, ist alles in einem Top-Level „Anwendung“ Objekt wickeln, die Transaktionen zwischen Models und ermöglicht Controllern arbeitet ein Verfahren des anderen aufzurufen. Ich habe das implementiert gesehen, aber ich bin nicht davon überzeugt, dass es eine gute Idee ist. Ich sehe auch Möglichkeiten, Controller zu verwenden, die mehr als ein Modell beobachten und auf mehr als eine View reagieren, aber das scheint so, als würde es sehr unübersichtlich und schwer zu folgen sein. Beste

Vorschläge, wie diese Art von Übersprechen zu implementieren? Ich fühle mich wie eine sehr offensichtliche Frage, aber ich konnte keine gut dokumentierte Lösung finden.

Auf einer breiteren Kenntnis, wenn jemand einen Link hat, die diese Art von MVC Probleme typische Ansätze zeigt, würde ich gerne sehen. Ich hatte nicht viel Glück, solide, nicht triviale Referenzen zu finden. Beispiele in Python wären schön, aber ich lese gerne alles.

Edit 1:

ich einige ziemlich interessante Dinge siehe unten und im allgemeinen niemand gesagt scheint ein Problem mit dem Ansatz habe ich beschrieben habe. Es ist schon fast eine faule Form des FrontController-Designs, das Vincent beschreibt. Ich sehe sicherlich keine Probleme bei der Umsetzung dieses Schemas, aber es scheint nicht, dass jemand wirklich die Frage in Bezug auf die Kommunikation zwischen Models angesprochen hat. Alle Antworten scheinen sich auf die Kommunikation zwischen Objekten in einem einzigen Modell zu beziehen. Ich bin mehr daran interessiert, separate Modelle für einzelne Komponenten der Anwendung zu pflegen, so dass ich nicht fünfzig Zustandseigenschaften in eine einzige Modellklasse stopfen kann. Sollte ich sie stattdessen als Untermodelle beibehalten?

Answer 1

Sie können die Front Controller aufzublicken Design-Muster zu betrachten.

Das Front-Controller-Muster definiert eine einzelne Komponente, die für die Verarbeitung von Anwendungsanforderungen zuständig ist. Ein Front-Controller zentralisiert Funktionen wie Ansichtsauswahl, Sicherheit und Templating und wendet sie konsistent auf alle Seiten oder Ansichten an. Wenn sich das Verhalten dieser Funktionen ändern muss, muss daher nur ein kleiner Teil der Anwendung geändert werden: der Controller und seine Hilfsklassen.

Auf diese Weise gehen alle Anfragen von der View an den FrontController, der dann entscheidet, welche spezifische Aktion (Controller) aufgerufen werden soll. Manchmal könnte es direkt zu einer anderen Ansicht als in Ihrem ersten Fall weitergeleitet werden.

Es gibt kein Problem mit mehreren Objekten im Modell, die miteinander kommunizieren. In der Tat wird das sehr üblich sein. So wie ich es sehe, wirken alle Objekte im Modell wie eine Komponente, um die Daten und Operationen auf den Daten darzustellen.

This Artikel könnte helfen. Und this eins.

Answer 2

In Bezug auf (1) rufen Views keine anderen Views auf. Sie rufen Controlleraktionen auf, die dazu führen können, dass andere Ansichten gerendert werden. In Ihrem Fall enthält das primäre Anwendungsfenster ein Benutzeroberflächenelement (Schaltfläche, Link), das eine Controller-Aktion zum Anzeigen des Einstellungsfensters aufruft.

In Bezug auf (3) könnten Modellkomponenten durchaus miteinander verwandt sein. Dies ist nicht unerwartet und sollte nicht unbedingt vermieden werden. Zum Beispiel könnte Ihr Kundenmodell eine Reihe von Bestellungen enthalten. Es wäre ganz natürlich, über eine Methode der Kundenklasse auf die Bestellungen des Kunden zuzugreifen.

Sie können einen Blick auf die MVC page auf Wikipedia für einen Überblick werfen.

Answer 3

Modell bedeutet nicht ein einzelnes Modellobjekt. Das Modell ist die Teilmenge des gesamten Domänenmodells, die in direktem Zusammenhang mit den Controller-Aktionen und den betreffenden Ansichten steht.