Ich habe dies ein paar verschiedene Möglichkeiten gesehen. Es ist lustig, wie alle Muster auf dem Papier perfekt aussehen, und dann zeigen die Details der Implementierung, dass es nicht so einfach ist. Ich werde Beispiele als MVW (Model-View-Whatever) geben, weil es in jedem Muster ähnlich sein sollte.
Option 1: Bindung an eine Eigenschaft. Dies ist ein wenig schwieriger mit WinForms, funktioniert aber gut mit WPF. Stellen Sie mit Ihrem Button eine bool-Eigenschaft auf Ihrem Presenter/Controller/Viewmodel ein. Ihre Ansicht zeigt oder verbirgt dann basierend auf diesem Wert die Benutzeroberfläche. Die UI kann alle vorhandenen UI überlagern, um das Aussehen eines Modals zu haben.
Option 2: Dienstleistungen. Führen Sie einen DialogService ein (hoffentlich haben Sie Dependency-Einstellungen eingerichtet, so dass es einfach ist, sie hinzuzufügen). Dieser Dienst verfügt über eine Methode von ShowDialog (Optionen). Optionen können Titel, Nachricht, Befehle (mit Titeln und Aktionen für Schaltfläche) sein. Legen Sie mit der Schaltfläche eine Eigenschaft fest oder geben Sie einen Befehl für den Moderator ein, der dann die showDialog-Methode von dialogService aufruft. Auf diese Weise ruft Ihre Ansicht einfach nur Ihren Moderator an, und dieser verwendet den Service. Aufrufe sollten nicht über Dienste wissen. Dadurch kann Ihr DialogService die entsprechende Benutzeroberfläche erstellen und anschließend das neue Formular starten. Dies ist auch, wie ich die nativen MessageBox.Show-Aufrufe, so dass Sie alle diese mit einem DialogService ersetzen können.
Option 3: Seien Sie kein Purist. Wenn Ihr Modal nicht mit einem Moderator interagieren muss oder Sie einfach nur grundlegende Daten zurück haben wollen (sagen Sie einen Farbwähler oder etwas Ähnliches), dann lassen Sie Ihren Blick darauf achten. Ihre Schaltfläche kann einfach das Modal öffnen, das Modal enthält Werte, die zurück an die Ansicht gesendet werden. Dann benutzt deine Ansicht sie. Wenn die Daten keinen Grund haben, zu einem Moderator zurückzukehren, sollten Sie die Dinge nicht zu einem Puristen machen. Ansichten können weiterhin UI-basierte Logik ausführen. Ich benutze die Ansicht für viele UI-Objekte, wie z. B. das Bewegen von Elementen mit Maus/Touch-Ereignissen oder Pinch-to-Zoom-Berechnungen. Wenn Logik nur UI ist, behalten Sie sie im Code der Ansicht. Wenn die UI-Logik wiederholt wird, verschieben Sie sie in einen Dienst, ein Benutzersteuerelement oder eine benutzerdefinierte Ansicht.
In allen MVP/MVC/MVVM-Dokumenten fehlen immer wichtige Details. Service ist für mich das fehlende Glied. Sie ermöglichen das Anschließen von lose gekoppelter Logik, und Sie können einige der hässlichen UI-Bindungen oder UI-Ereignisse in Dienste einbinden und für Ordnung sorgen.
Hoffe, das hilft.
Nun, es kommt darauf an. Wenn Sie das Erstellen von Ansichten verallgemeinern können, handelt es sich möglicherweise um den P-Bereich. Wenn solche Ansichten keinen Einfluss auf die Geschäftslogik haben, können Ansichten solche Ansichten selbst erstellen, ohne dass ein Moderator mit ihnen interagieren muss.Angenommen, Sie haben eine einfache Google Maps-basierte Anwendung, kann Ihre Google Map-Instanz _may_ interne Ansichten erstellen, die mit dem _main_-Moderator interagieren und nicht einmal wissen lassen, dass eine Teilansicht mit dem Moderator interagiert. Ich würde standardmäßig für den ersten gehen, da der zweite Ansatz die Interaktion komplexer macht. –
Keine der Ansichten hat Einfluss auf die Geschäftslogik, soweit ich weiß (vorerst jedenfalls). Mein Verständnis von MVP hat etwas mit der Benutzeroberfläche zu tun, sollte in der Ansicht erfolgen, und der Präsentator muss sich nur mit der Manipulation der Ansichts- und Modelleigenschaften befassen, sollte aber keine UI-Elemente erstellen. – Jake