Ich bin hauptsächlich ein Webentwickler, aber ich habe ein sehr gutes Verständnis von C ++ und C #. In letzter Zeit habe ich jedoch eine GUI-Anwendung geschrieben, und ich habe begonnen, mich damit zu befassen, wie ich mit der Beziehung zwischen meiner Steuerung und der Ansichtslogik umgehen soll. In PHP war es sehr einfach - und ich konnte mein eigenes MVC-Muster mit meinen geschlossenen Augen schreiben - hauptsächlich wegen der Tatsache, dass PHP statusfrei ist und man das gesamte Formular pro Anfrage neu generiert. Aber in Anwendungsprogrammiersprachen bin ich sehr schnell verloren.
Meine Frage ist: Wie würde ich meinen Controller von der Sicht trennen? Sollte die Ansicht an Ereignisse vom Controller anhängen - oder sollte die Ansicht eine Schnittstelle implementieren, mit der der Controller interagiert?
Wenn ich du wäre, würde ich Ereignisse von einer Schnittstelle deiner Ansicht aus darstellen. Auf diese Weise können Sie den Controller für die gesamte Interaktion zentral machen.
Der Controller lädt zuerst und instanziiert die Ansicht. Ich würde die Abhängigkeitsinjektion verwenden, damit Sie keine Abhängigkeit von der Ansicht selbst, sondern nur von der Schnittstelle erstellen. Der Controller würde auf das Modell zugreifen und Daten in die Ansicht laden. Der Controller würde an Ereignisse gebunden, die auf der Ansichtsschnittstelle definiert sind. Der Controller würde dann die Speicherung von Daten über ein Ereignis in das Modell übernehmen.
Wenn Sie möchten, können Sie auch einen Event-Broker verwenden, bei dem die Deklaration einer Schnittstelle pro Sicht entfällt. Auf diese Weise können Sie Ereignisse über Attribute binden.
Dies würde dazu führen, dass der Controller vom Modell und der Ansichtsschnittstelle abhängig ist, wobei die Ansicht nur von den Daten abhängig ist und das Modell keine Abhängigkeiten aufweist.
Einige Beispiele für das obige Design Thinking finden Sie in CAB und in der Smart Client Software Factory Link zu Smart Client . Sie verwenden das MVP-Muster, aber es könnte ebenso leicht auf das MVC-Muster angewendet werden.
Fast jedes GUI Framework (von MFC zu SWT zu was auch immer) ist bereits MVC basiert. Tatsächlich wurde das MVC-Muster zuerst von Smalltalk-80 erstellt und später erst wirklich für die GUI-Entwicklung verwendet.
Überprüfen Sie die Standards und empfohlenen Vorgehensweisen für Ihr GUI-Toolkit. Manchmal ist MVC kein gutes Muster, mit dem man arbeiten kann, wenn man ein bestimmtes Problem löst oder mit einem bestimmten Toolkit arbeitet.
Denken Sie daran: MVC ist ein großartiges Muster, aber es ist keine universelle Lösung. Versuchen Sie nicht, ein Problem in MVC zu erzwingen, wenn die ereignisbasierte oder funktionale Stilprogrammierung Ihnen das Leben erleichtern wird.
Stellen Sie sich diese GUI vor:
Die Zergling-Einheit wird dem Benutzer als Alien-Symbol angezeigt. Sie können sehen, dass es in seiner Leerlaufanimation ist. Nennen Sie das die Ansicht.
Der Spieler bewegt die Einheit, indem er darauf und einen Zielort klickt. Sie können den Spieler für eine KI ersetzen, wenn Sie möchten. Nenne dies den Controller.
Der HP- und Angriffsbereich der Einheit wird für jeden Spielrahmen berechnet, wenn sich die Einheit im Kampf befindet. Sie können diese Daten ändern, um den Zergling zu einer Bereichseinheit zu machen. Nenne dies das Modell.
Behalten Sie diese Analogie im Hinterkopf und erweitern Sie sie für Ihre MVC-Designs.
Das Wichtigste für Sie, sich daran zu erinnern, ist, dass der Controller in Ihrem MVC-Setup wissen muss, welche View aufgerufen werden soll, aber die View muss nichts vom Controller wissen.
Ihre View muss also eine generelle Möglichkeit für Controller bieten, damit zu interagieren, so dass mehrere verschiedene Controller die gleiche View aufrufen können (eine standardisierte grafische Ausgabe einiger Daten, die als Parameter zur Verfügung gestellt werden).
Dies gibt Ihnen Flexibilität:
Wenn Sie Ihre Ansicht von bestimmten Controllern getrennt halten und wissen, welche View von Ihrem Controller aufgerufen werden soll, sind Sie auf dem besten Weg.
Ihr Controller sollte definitiv an Ereignisse gebunden sein, die auf einer Schnittstelle definiert sind, die die Ansicht implementiert.
Wie Sie dabei vorgehen, kann der knifflige Teil sein. Abhängigkeitsspritze? Eine Ansichtsfabrik? Lassen Sie die Ansicht den gewünschten Controller instanziieren? Es hängt wirklich davon ab, wie komplex die Anwendung sein wird.
Für etwas, das wirklich schnell und einfach ist, würde ich damit beginnen, dass jede Ansicht ihren Controller erstellt und dann andere Optionen betrachtet, wenn sie größer werden sollte. Persönlich denke ich, dass ein vollständiges Abhängigkeits-Injection-Framework für ein halbes Dutzend Formen übertrieben ist:]
Tags und Links c# c++ user-interface model-view-controller design-patterns