Model-View-Controller Fail?

[HazelNut]

Hallo also ich muss eine Anwendung programmieren.
Und zwar mit dem MVC Pattern.
(Mal ne Frage was ist der unterschied zu Architektur und Entwurfsmustern?)
Jedenfalls soll diese aus einem Controller, welcher selbst eine GUI erzeugt, 2 Views und einem Model bestehen.
Ich bin mir nun nicht wirklich sicher ob ich es korrekt realisiert habe und hoffe mal ein paar können schnell mal drüber schauen und evtl Fragen beantworten

main:
Swingworker(
controller = new Controller();
);

Controller:
Erstellt mal seine GUI;
Instanziert das Model;

nimmt ein paar eingaben entgegen, und wenn ein Btn gedrückt wird erstellt er (
die beiden Views;
teilt dem model die Eingabe mit;
sagt dem model, dass die eingabe geparst werden soll;
);

Model extends Observable:
macht halt Model Stuff.. zudem verständigt er die Observer in einer Methode, die vom Controller aufgerufen wird.

View implements Observer:
Eine GUI halt....

update(){
new Model(){hole vom Model geparste Werte};

Des weiteren würde mich interessieren ob das passt, dass die View vom Model die Werte holt?
Laut MVC sollte es doch nicht das Model kennen oder doch?
Weil wenn ich das jetzt wieder umschreibe dann sind die Views ja erst vom Model abhängig.

Vom MVC gibt es irgendwie keine einheitliche Implementierung.
Der eine verwendet Actionlistener der andere Observer und dann gibt es wieder leute bei denen das Model die Views nicht kennt.

Wie schaut es aus mit Swingworker? ich habe zwar schon ~zwei Seiten über den geschrieben aber weis noch immer nicht weshalb ich denn verwenden sollte für eine GUI bzw einen zeitfressenden Algo welcher nach einer Buttonbetätigung ausgeführt wird, anstatt eines normalen Threads?

 

[Camino]

Wie schaut es aus mit Swingworker? ich habe zwar schon ~zwei Seiten über den geschrieben aber weis noch immer nicht weshalb ich denn verwenden sollte für eine GUI bzw einen zeitfressenden Algo welcher nach einer Buttonbetätigung ausgeführt wird, anstatt eines normalen Threads?

Bei Google "java" und "swingworker" eingegeben, dann finde ich fast ganz oben das:
SwingWorker Tutorial
Da wird das in ein paar Sätzen erklärt, wozu und warum den SwingWorker.

 

[Spacerat]

So unheimlich fest ist MVC afaik gar nicht definiert. Nicht alles, was man bei Wikipedia liest, stimmt 100%ig. Man kann den Controller als Vermittler implementieren, in diesem Fall würde das Model die View mittels des Controllers über Änderungen in der Darstellung informieren und Model und View würden sich nicht kennen müssen. Andernfalls kann sich die View auch sowohl beim Model als auch beim Controller als Listener registrieren. Der Controller verarbeitet dann nur Benutzereingaben und informiert das Model entsprechend. Das Model informiert dann seinerseits die View über geänderte Daten in der Darstellung.
Der Informationsfluss findet über Observer und Observable statt und Events sind damit durchaus vergleichbar, nur dass Events halt in einem EDT gesammelt werden, während reine Observables ihre Observer direkt informieren.
Bei MVC kann es durchaus sein, dass ich da Fehlinformationen unterlegen bin. In diesem Fall korregiert mich bitte.

 

[HazelNut]

Bei Google "java" und "swingworker" eingegeben, dann finde ich fast ganz oben das:
SwingWorker Tutorial
Da wird das in ein paar Sätzen erklärt, wozu und warum den SwingWorker.

Du hast meine Frage nicht ganz deutlich gelesen oder?
Ich weis wohl das dadurch komplexe Algos in eigene "Threads"? ausgelagert werden damit die GUI nicht blockiert, aber ich weis nicht weshalb den Swingworker verwenden und nicht einfach einen neuen Thread erstellen, und ja ich weis, das SW Runnable implementiert.

Spacerat...

Ja, habe auch schon öfters gelesen, das es nicht wirklich "fix" ist.
Warum darf ich jetzt zb nicht direkt vom View das Model zugreifen?
Ich meine, in meinem Beispiel (und vielen anderen auch) kennen die Views mein Model ja auch.
Der COntroller ist ja bei mir mehr oder weniger komplett nutzlos, denn wenn ich jetzt die Views austausche muss ich doch auch den abändern. Dann kann ich ja gleich von den Views aufs Model.

 

[Spacerat]

Die View ist stets das passive Element, es dient nur der Visualisierung der Daten aus den Quellen Model und Controller. Deswegen ist es nicht der Part der View bei den anderen beiden Elementen ständig nachzuhaken, ob es Änderungen gibt (würde afaik zwangsläufig in Busy Waiting enden). Der Controller ist in soweit auch niemals nutzlos, denn Benutzerinteraktionen (Mouse, Keyboard, Blätterteig) haben weder was im Model zu suchen und schon gar nicht im View.

 

[Ranjo]

Ich kenne es nur so, dass das Model der View übergeben wird.
Würde die auch empfehlenmit Observer zu arbeiten, ersten ist hier der Lerneffekt größer und das ganzw wird auch überscihtlicher anstatt mit zu vielen Listenern zu arbeiten.

Gruß
Ranjo

 

[Camino]

Du hast meine Frage nicht ganz deutlich gelesen oder?
Ich weis wohl das dadurch komplexe Algos in eigene "Threads"? ausgelagert werden damit die GUI nicht blockiert, aber ich weis nicht weshalb den Swingworker verwenden und nicht einfach einen neuen Thread erstellen, und ja ich weis, das SW Runnable implementiert.

Hmm, vermutlich ist der SwingWorker eine Vereinfachung und du könntest auch einen Thread nehmen. Beim SwingWorker gibt es halt noch so nützliche Methoden wie publish() und done().
http://www.java-forum.org/java-basics-anfaenger-themen/68477-unterschied-zwischen-swingworker-normalem-th.html

 

[HazelNut]

Camino

Hmm okay, das Javadoc und die Methoden von SW habe ich mir bereits angeschaut, sind wohl wirklich der einzige Unterschied.

MVC:
Hmm und warum sollte ich dann nicht einfach wenn im View ein Btn gedrückt wird diesen im Controller registrieren? Und der sagt dann dem Model, dass etwas gemacht werden soll.
Weil wenn ich es so mache wie zur zeit, teile ich von ner View eine eingabe an das Model mit und übergebe die Werte der View an das Model.
Und wenn die Werte dann geparst sind sagt das Model das den Observern, also den Views, das was passiert ist und die Views kennen dann das Model, weil sie ja auf die Werte zugreifen müssen.
Hmm, wenn mans so sieht kennt das Model die Views nicht und dann passt diese Art der MVC-Implementierung ja?
Und der Controller ist so wie normalerweise auch mit den Views "verbandelt".

Dürfte ich jetzt wenn eine View geschlossen wird (was dann ja in der jeweiligen View abgehandelt wird) von dort direkt eine Checkbox im Controller setzen? - Was anderes wird mir wohl nicht übrig bleiben.

 

[Spacerat]

Hmm und warum sollte ich dann nicht einfach wenn im View ein Btn gedrückt wird diesen im Controller registrieren? Und der sagt dann dem Model, dass etwas gemacht werden soll.
Weil wenn ich es so mache wie zur zeit, teile ich von ner View eine eingabe an das Model mit und übergebe die Werte der View an das Model.
Und wenn die Werte dann geparst sind sagt das Model das den Observern, also den Views, das was passiert ist und die Views kennen dann das Model, weil sie ja auf die Werte zugreifen müssen.

...weil die InputListener (ActionListener der Buttons gehören dazu) ver View im Controller liegen. Die View bekommt also zunächst erst mal gar nichts davon mit, dass einer ihrer Buttons betätigt wurde. Erst wenn der Event an das Model weitergeleitet wurde und dort daraus eine Änderung der View hervorgeht, kann das Model die View (ob über Controller oder direkt ist dabei relativ egal) darüber informieren.

Dürfte ich jetzt wenn eine View geschlossen wird (was dann ja in der jeweiligen View abgehandelt wird) von dort direkt eine Checkbox im Controller setzen? - Was anderes wird mir wohl nicht übrig bleiben.

Eigentlich nicht... die View ist immer noch das passive Element der "Kette". Wenn jemand 'ne View schliesst, dann entweder der Controller oder das Model und da letztere ohnehin miteinander kommunizieren, muss die View auch niemanden darüber informieren, dass sie geschlossen wurde.

 

[HazelNut]

...weil die InputListener (ActionListener der Buttons gehören dazu) ver View im Controller liegen. Die View bekommt also zunächst erst mal gar nichts davon mit, dass einer ihrer Buttons betätigt wurde. Erst wenn der Event an das Model weitergeleitet wurde und dort daraus eine Änderung der View hervorgeht, kann das Model die View (ob über Controller oder direkt ist dabei relativ egal) darüber informieren.

Ahh okay, dann müsste ich noch die ganzen Action-Btns auslagern, was bei mir ja entfällt da der Controller selbst die Main GUI ist ( es ist so gefordert).

Eigentlich nicht... die View ist immer noch das passive Element der "Kette". Wenn jemand 'ne View schliesst, dann entweder der Controller oder das Model und da letztere ohnehin miteinander kommunizieren, muss die View auch niemanden darüber informieren, dass sie geschlossen wurde.

Vielleicht habe ich mich unklar ausgedrückt.
Es ist möglich das der Controller die Views schließt.
Ich möchte nur erreichen, dass wenn ein User ein View mit X schließt, dies der Controller erfährt und den jeweiligen Checkbox entsprechend setzt.

 

[Spacerat]

Vielleicht habe ich mich unklar ausgedrückt.
Es ist möglich das der Controller die Views schließt.
Ich möchte nur erreichen, dass wenn ein User ein View mit X schließt, dies der Controller erfährt und den jeweiligen Checkbox entsprechend setzt.

Nein, du hast dich nicht unklar ausgedrückt. Ich hab' evtl. vergessen (eigentlich hielt ich das für offensichtlich ) zu sagen, dass der WindowListener einer View ebenfalls im Controller untergebracht würde. Dann schliesst nämlich auch in diesem (vorläufig) letzten Fall der Controller die View.

 

[bERt0r]

Ich erklärs dir am Button: Ein Button hat auch eine View, das is eine Klasse die dieses Rechteck mit den abgerundeten Ecken zeichnet. Wird jetzt aber ein Button ausgelöst (z.b durch Mausklick oder enter -> Maus und KeyListener) wird erstmal der/ein Controller des Buttons angesprochen, es muss auf das Maus/Key Event reagiert werden. Die Reaktion ist, das Model zu benachrichtigen dass der Button gedrückt wurde. Das Model wirft jetzt ein neues ActionEvent und benachrichtigt die View, dass es den Button als gedrückt zeichnen soll.

Disclaimer: Ob jetzt das Model oder der Controller in dem Fall das ActionEvent werfen soll ist streitfrage. Das ist afaik nicht genau definiert, ist aber auch ziemlich egal hier. Ich finde es schöner das Model als "Arbeitsobjekt" zu sehen und den Controller nur quasi als "Chef" der dem Model Anweisungen gibt.

 

[Spacerat]

[OT]

...nur quasi als "Chef"...

Ach ja... und als solcher hat man quasi nichts zu melden... Das ist so die typische Betriebsweihnachtsfeierkonversation: "Oooch is' ja nur der Chef, der muss das abkönnen..." :lol:[/OT]

 

[Codeschnipsel]

...weil die InputListener (ActionListener der Buttons gehören dazu) ver View im Controller liegen.

D.h. dass alle Listener, die Veränderungen am Model zur Folge haben im Controller liegen und alle Listener, die nur Auswirkungen auf die View haben, in der View liegen?

 

[Spacerat]

D.h. dass alle Listener, die Veränderungen am Model zur Folge haben im Controller liegen und alle Listener, die nur Auswirkungen auf die View haben, in der View liegen?

Äh, nein... es gibt keine Listener, die nur Auswirkungen auf die View haben. Der Controller ist der alleinige Empfänger von Benutzerinteraktionen (Buttonklicks, Werteingaben, Tastatur-Shortcuts usw). Sogar der WindowListener sollte im Controller liegen. Die View ist nur passiv und kann ggf. vom Controller oder dem Model dazu aufgefordert werden, sich zu aktualisieren (z.B. durch "repaint()"). Die dafür nötigen Parameter liefert ebenfalls entweder der Controller oder das Model.

 

[Codeschnipsel]

D.h. alle Listener liegen im entsprechenden Controller? Bzw. es gibt keine Listener in der View?

 

[Spacerat]

D.h. alle Listener liegen im entsprechenden Controller? Bzw. es gibt keine Listener in der View?

Meines Erachtens korrekt. Setter für die Darstellungsparameter würde ich jedenfalls nicht als Listener betrachten.

 

[Codeschnipsel]

Warum im Controller und nicht in der View? Was sind die Vor- und Nachteile?

In einem Artikel bei Oracle werden die Listener in die View geschrieben. Das habe ich bisher am häufigsten gesehen.

 

[HazelNut]

Nein, du hast dich nicht unklar ausgedrückt. Ich hab' evtl. vergessen (eigentlich hielt ich das für offensichtlich ) zu sagen, dass der WindowListener einer View ebenfalls im Controller untergebracht würde. Dann schliesst nämlich auch in diesem (vorläufig) letzten Fall der Controller die View.

Hehe, ja danke das ich dann einfach darauf zugreifen kann ist mir nach 3min auch wieder eingefallen
Das "Problem" ist nur das meine Views nicht von JFrame erben sondern es nur per Komposition? verwenden.
Das heißt also das ich extra dafür wieder eine Methode in meinen Views definieren muss und das nur um zu bestimmten was geschieht wenn sie geschlossen werden..... :\
Ist es in diesem Fall vielleicht doch klüger Vererbung zu verwenden?

@ober mir:
Den Artikel hab ich auch verwendet :=
Zudem noch einen in dem von PUSH und PULL Interaktion der Komponenten die rede ist.
Hier

 

[Spacerat]

Warum im Controller und nicht in der View? Was sind die Vor- und Nachteile?

Die saubere Trennung von Eingabe, Verarbeitung und Ausgabe (EVA) würd' ich sagen. Es ist auch keine Schande, die Listener in die View zu packen, nur darf man nie vergessen, den Controller über auftredende Events zu informieren bzw. die Events an diesen weiter zu leiten. Das würde aber bedeuten, dass die View Kenntnis vom Controller haben muss. Letztendlich ist's doch nur 'ne Designfrage, wer wen kennen soll. Wenn man die Listener in der View hat kommt man recht schnell in die Verlegenheit Parameter der View zu ändern, ohne Model und oder Controller darüber zu informieren. Am Ende forscht man dann an den falschen Stellen nach Dateninkonsistenz.

@HazelNut: wieso denn gleich Vererbung? Schreib' 'ne Methode in die Views, wo ein Controller ControlListener registrieren kann. Da kannst du dann im Zweifelsfall sogar alle verwendeten Listener (sind ja durchweg Interfaces) als gebündelte Klasse übergeben. Naja... das dann doch eher unsauber, also vergiss das wieder (bis auf die Sache mit den Registrier-Methoden ).
Ausserdem haben "Views" (z.B. Swing-Komponenten) ja schon entsprechende Methoden: "dispose()", "setVisible()", "setEnabled()"... steht doch in deinem Link alles wunderbar beschrieben... (der Controller hat keine Listener, er ist ein Listener... auch nicht schlecht. Naja... XD)

 

[HazelNut]

Hmm irgendwie steh ich grad am Schlauch :noe:
Wie soll ich das jetzt machen, dass ich im Controller die addListener-Method von den Views aufrufe und im COntroller spezifiziere was beim Eintreten des Events gemacht wird?

Achh, habe ich meine View ansonsten richtig geschriebenen?
Den in den update() von den Views verwende ich immer MyModel was ich eben durch das übergebene Observable o erhalte.
Dadurch ist das doch schon anfällig, wenn ich mein Model austausche.
Gibt es da eine schönere Möglichkeit? Was ich gesehen habe kann man mit notifyObservers() ein Objekt übergeben nur wie soll ich meine verschiedenen Werte mit einem Aufruf davon übergeben?

 

[Spacerat]

Die Views brauchen diese add-/removeListener Methoden, nicht der Controller. Bei Komposition, must du in diesen Methoden die Listener nur an die jeweiligen Komponenten weiterleiten. Selbiges gilt für benötigte Getter und Setter der Komponenten. Controller und Model können die Views dann fast wie normale Komponenten behandeln, nur das denen halt jene Methoden der Komponenten, welche die View weder implement noch delegiert, verborgen bleiben.

 

[HazelNut]

ehmm ich muss zugeben das ichs noch immer nicht verstehe.
Aber ich habs mal so gemacht:

view:
void createListener(WindowAdapter a){
frame.addWindowListener(a);
}

Controller:
view.createListener(new WindowAdaper(){
auszuführender Code});

So ungefähr?

 

[Spacerat]

Jup. Aber ich würd' bei addListener bleiben, View created den Listener ja nicht.

 

[HazelNut]

Okay, danke sehr.

Würde mich eigentlich nur noch das mit meiner update() in den Views interessieren.
Ob ich das jetzt so verwenden darf oder nicht, weil bei einem wechsel des Models ist es ja wirklich blöd.

 

[Spacerat]

Dazu kann man die Getter und Setter der Komponenten plus deren "repaint()"-Methode nach aussen führen (also wie gehabt im View implementieren und an die Komponenten delegieren), dann kann man aus dem Model oder aus dem Controller diese aufrufen ohne das die View Kenntnis von beiden haben muss. Das macht die View dann von beiden völlig unabhängig und so wird auch ein Wechsel der beiden kein Problem.

Fehlt nur noch Eines: Evtl. fällt nun sofort auf, dass eine View eigentlich nichts anderes ist, als die Komponente um welche sie herum komponiert wurde. Die Preisfrage also, warum verwendet man nicht gleich die Komponente und spart sich diesen Kompositions-Schnick-Schnack. Die Antwort ist relativ simpel, denn mit "paintComponent()", "setLayout()", (evtl.) "setSize()" usw. kommt eine grosse ganze Reihe an Methoden zusammen, die nicht nach aussen getragen wurden und somit Sache der View bleiben. Das man beim Kompositions-Pattern nun noch ein offenes "extends" zur Verfügung hat, welches man ggf. für andere Zwecke verwenden kann, ist ein netter Nebeneffekt, jedoch völlig nebensächlich. Wichtig ist nur, dass einzig und allein die View für ihr Design und ihr eigenes Neuzeichnen selbst verantwortlich ist (sogar nur selbst verantwortlich sein kann, denn Controller und Model sehen ja z.B. "paintComponent()" usw. nicht mehr).

 

[Codeschnipsel]

Äh, nein... es gibt keine Listener, die nur Auswirkungen auf die View haben.

Wie sieht es bei folgendem Beispiel aus:
Der User kann den Abstand von 2 View-Komponenten ändern (z.B. über einen Slider). Diese Änderung hat mit dem Model nichts zu tun. Die Validierung der Eingabe erfolgt bereits durch den Slider, da ein Wertebereich festgelegt ist. Da sich nur der Abstand der 2 View-Komponenten ändert, hat der Listener nur Auswirkungen auf die View.

Habe ich etwas übersehen oder eine Fehler in meinem Gedankengang? ???:L

Werden Informationen, die nur für die Darstellung gedacht sind (z.B. Abstände), als Attribut in der View gespeichert? Kann ich dieses Attribut im oberen Beispiel weg lassen und den Wert immer vom Slider holen?

PS: Ich entschuldige mich schon mal im Voraus für alle haarsträubende Fragen, die in diesem Beitrag enthalten sind

 

[Spacerat]

Aber bitte... musst dich doch nicht entschuldigen.
Der Gedankengang ist schon nicht verkehrt, wäre ein ähnliches Beispiel wie mit "<View>.close()" (also die Betätigung des Schliess-Buttons). Die Bewegung des Sliders ist eine Benutzerinteraktion, die vom Controller empfangen werden sollte welcher dessen Werte an die View und an das Model übergibt. Hätte man die Listener nun in der View, wäre dies ein Fall, in welchem man der Verlegenheit unterliegt, dass sich das niemals auf das Model oder dem Controller auswirken könnte, weswegen man es auch nicht weiterleitet. Aber mal angenommen; Durch Ändern dieser Abstände ändern sich aus Platzgründen auch irgendwelche Textfelder, wodurch Daten, welche aus dem Model kommen, nicht mehr korrekt angezeigt würden. Wo würdest du diesen "Fehler" zuerst suchen? (Ich nehme mal an, du würdest jetzt "natürlich in der View" sagen, aber diese Antwort wäre rein subjektiv.)

 

[HazelNut]

Hmm okay, deine Begründung zur Komposition hört sich ja ganz plausibel an, aber:
Ich habe doch die Möglichkeit zu entscheiden wo ich es mache, wenn ich meine Views von JFrame erben lasse und so die Möglichkeit habe die paint() usw im Controller aufzurufen, dann ist das doch meine Entscheidung bzw die von den anderen Programmierern, ich werde doch nicht gezwungen es dort zu tun.
Klar, könnte man argumentieren, dass es dadurch schneller geht, dass ich das einfach mal "so" im Controller mache anstatt in der View aber das müsste man doch recht schnell bemerken.

Ach und zu update();
Ich implementiere doch Observer, sprich ich benötige diese Methode.
Oder meinst du, dass ich in der update() eine weitere Meldung an den Controller schicke, dass der mir die Daten aus dem Model holt und dann dem View gibt?
Obwohl dann meine view wieder den Controller kennt....

 

[Spacerat]

Sicher benötigt die View 'ne Updatemethode und man kann sie bei Komposition auch ruhig "update()" nennen und man delegiert dann halt zu "repaint()".
Was aber keinesfalls gehen sollte, ist das Controller und/oder Model jemals die Methoden "paint(Graphics)", "update(Graphics)", "paintComponent(Graphics)" und alle anderen Methoden die Graphics als Parameter haben aufrufen können. Diese Methoden (Ausgabe- bzw. Zeichenmethoden) sind allein Sache der View.
Verwendet man Komposition nicht, so ist es ein Sakrileg (ein fataler Fehler) diese Zeichenmethoden aus dem Controller und oder dem Model aufzurufen. Diese Methoden sind Sache des EDT und entsprechende Events löst man ausschliesslich mit "repaint()" aus.

Ob du nun die darzustellenden Daten direkt oder über den Controller an die View schickst ist relativ egal. Evtl. muss das Model auch gar nichts machen und der Controller holt sich bei jedem Ereignis aktualisierte Daten aus dem Model und leitet diese an die View. Anschliessend aktualisiert der Controller dann auch die View. Dann ergäbe sich für einen Controller folgendes Konstrukt:

Model m = new Model();
View v = new View();
Controller c = new Controller(m, v);

class Controller {
  private final View view;
  private final Model model;

  public Controller(Model m, View v) {
    model = m;
    view = v;
    view.addListener(new ControllerListener());
  }
}

Weder View noch Model müssten den Controller kennen. Nur der Controller weiss über die anderen beiden bescheid... nun ist der Controller wirklich Chef.

 

[HazelNut]

Ja, das habe ich schon verstanden

Hmm, also müssten meine Views doch gar nicht Observer implementieren?
Wäre es zu empfehlen, dass der Controller das macht?
Weil der kennt dann eh das Model, und holt sich dann nach update() halt die Daten vom Model und leitet sie an die entsprechenden Views weiter.

2.)
Hmm du meinst, dass ich gar nicht Observable verwenden soll?
Würde auch gehen, mein Controller weis ja, wenn er etwas zum Model schickt, dann holt der die geparsten Werte raus und gibt sie an die views weiter, ginge auch.

 

[Spacerat]

Weis nicht, ob ich das schon irgendwo erwähnt hatte, aber ein Eventsystem ist eine erweiterte Art des Observerpatterns. Observables informieren ihre Observer direkt und in Eventsystemen informieren sie sie (hier heissen sie Listener) über einen separaten EventDispatchThread (EDT). Bei Observables bekommen die Observer die Informationen sofort, in Eventsystemen landen sie zunächst in einer Queue, die vom EDT nach und nach abgearbeitet wird.
Bei den Views würde ich auf jeden Fall Events verwenden, weil das bietet sich an, da ohnehin bereits in den Komponenten implementiert.
Beim Model ist die Frage, ob überhaupt und wenn ja wieviele darstellungsrelevante Informationen müssen in einem Zeitfenster geschaufelt werden (Datenvolumen). Hinzukommt die Entscheidung, wie zeitnah diese zur Verfügung stehen müssen. Müssen sie sofort zur dargestellt werden, geht das nur mit Observables.
Bei meinem Konstrukt oben, aktualisiert der Controller je nach Ereignisquelle nur die View oder Model und View. Wenn die Quelle die View war (kann im Prinzip nur eine Benutzerinteraktion sein) wird Model und View aktualisiert war es das Model, wird halt nur die View aktualisiert. Das Model kann sich selber aktualisieren, bei der View ist das unangebracht.