Komponentenübergreifende Kommunikation innerhalb einer Ansicht (MVC)

Question

Welche bewährten Verfahren gibt es, um die Interaktion zwischen komplexen Komponenten in Ihrer Ansicht zu orchestrieren?

Ich spreche nicht von einfachen Widgets wie einem Kombinationsfeld oder einem Grid-Steuerelement, sondern von Komponenten, die aus mehreren Widgets bestehen und die es verdienen, einzeln getestet zu werden.

Würden Sie das tun?

1. Definieren Sie abstrakte Schnittstellen für jede Komponente, lassen Sie den Controller sie über Dependency Injection miteinander verbinden, damit sie über Methodenaufrufe direkt miteinander kommunizieren können? Die Komponenten kennen also die Schnittstellen der anderen Komponenten.
2. Definieren Sie Ereignisse, die jede Komponente auslösen kann und lassen Sie den Controller sie direkt über Ereignislisten aneinander koppeln? Die Komponenten haben daher Ereignisbehandler, die an die Ereignissenken anderer Komponenten angeschlossen sind.
3. Definieren Sie abstrakte Schnittstellen für jede Komponente, definieren Sie Ereignisse, die sie auslösen können, und lassen Sie den Controller auf alle Ereignisse hören und Methodenaufrufe an den Schnittstellen durchführen? Die Komponenten sind daher gegenüber anderen Komponenten völlig unabhängig.
4. Eine klassische Anwendung des Observer-Musters?
5. Sonst noch etwas?

更新しました。 Ich habe "let the Controller ..." aus #1-3 gestrichen, weil es nicht unbedingt der Controller ist, der in diesen Fällen das Routing/die Orchestrierung durchführen muss. Es könnte die Ansicht selbst sein.

Ich habe die Methode Nr. 3 in einem aktuellen Projekt angewandt und war mit der Entkopplung und der individuellen Testbarkeit der Komponenten zufrieden. Ich habe jedoch das Gefühl, dass ich die Verdrahtung der Komponenten rationalisieren könnte. In meinem Fall muss das Haupt-View-Objekt mehrere Event-Listener für jede Komponente hinzufügen und dann Methoden für die entsprechenden Komponenten aufrufen, nachdem es manchmal einige lokale Verarbeitungen vorgenommen hat (z. B. Gespräche mit dem Model). Der Code für das Hinzufügen der Ereignishandler sieht etwas unübersichtlich aus, und ich bin vor allem auf der Suche nach einer sauberen Möglichkeit, das zu tun.

Answer 1

Option 3 klingt wie das Mediator-Muster und ist oft der beste Ansatz, wenn die Aktualisierungslogik und die Kommunikation zwischen den Objekten komplex ist. Sie hat auch den zusätzlichen Vorteil, dass die Steuerlogik und die Initialisierung zentralisiert bleiben, was die Nachverfolgung und Fehlersuche in solchen Fällen erleichtert.

Answer 2

Es klingt, als hätten Sie das Wissen, um Ihre eigene Frage zu beantworten, aber vielleicht fehlt Ihnen einfach das Selbstvertrauen, um sich darauf einzulassen. Sind Sie nur auf Entdeckungsreise oder stecken Sie irgendwo fest?

Ich würde noch hinzufügen, dass man zusätzlich einen Komponentenmanager zwischen alle Objekte schalten kann, um die Kommunikation zu erleichtern. In der Vergangenheit, als ich etwas Ähnliches gemacht habe, endete das Verwaltungsobjekt damit, dass es einfach Daten von jeder Komponente nahm, die Daten zusammenführte und sie als eine große Anfrage an das Modell weitergab. Jede meiner Komponenten hatte einen Delegaten, den sie aufrief und an den sie Daten weitergab, und natürlich lag die Implementierung dieses Delegaten in meinem Komponentenmanager.

Ich habe das Manager-Objekt auch als Proxy für das Netzwerk agieren lassen. Ich habe darauf gewartet, dass die Komplexität höher wird, bevor ich mich an SRP gehalten habe und diese Verantwortung zu einer eigenen Klasse gemacht habe.

Im Grunde klingt alles, was Sie gesagt haben, gut. Ich würde empfehlen, einfach einzutauchen und zu erkunden.