Was ist der richtige Weg, Messenger class zu verwenden?
Ich weiß, dass es für ViewModels / Views-Kommunikationen verwendet werden kann, aber ist es ein guter Ansatz, es für eine technische / Business-Service-Ebene zu verwenden?
Beispielsweise registriert sich ein Protokollierungs- / Navigationsdienst für einige Nachrichten in den Konstruktoren und erkennt, wenn diese Nachrichten in der App auftreten. Der Absender (ViewModel ou Service) verweist nicht auf die Serviceschnittstelle, sondern nur auf den Messenger zum Senden von Nachrichten. Hier ist ein Beispieldienst:
%Vor%Für mich ist der hauptsächliche Gebrauch eines Messenger, weil er die Kommunikation zwischen viewModels ermöglicht. Nehmen wir an, Sie haben ein Viewmodel, das verwendet wird, um Business-Logik zu einer Suchfunktion und 3 Viewmodels auf Ihrer Seite / Fenster, die die Suche verarbeiten möchten, um Ausgabe anzuzeigen, der Messenger wäre der ideale Weg, dies lose zu tun Weg.
Das Ansichtsmodell, das die Suchdaten erhält, würde einfach eine "Such" -Nachricht senden, die von allem konsumiert würde, das gerade für den Verzehr der Nachricht registriert war.
Die Vorteile hier sind:
Bearbeiten: Also, was ist mit Dienstleistungen?
In ViewModels geht es darum, wie Daten auf der Benutzeroberfläche dargestellt werden. Sie nehmen Ihre Daten und formen sie zu etwas, das Ihrem View präsentiert werden kann. ViewModels erhalten ihre Daten von Diensten.
Ein Service stellt dem ViewModel die Daten und / oder Geschäftslogik zur Verfügung. Der Service-Job dient dazu, Business Model-Anforderungen zu bedienen. Wenn ein Dienst andere Dienste kommunizieren / verwenden muss, um seine Aufgabe zu erledigen, sollten diese mit Hilfe der Abhängigkeitsinjektion in den Dienst eingefügt werden. Dienste würden normalerweise nicht mit einem Messenger kommunizieren. Der Messenger handelt sehr stark von horizontaler Kommunikation auf Viewmodel-Ebene.
Eine Sache, die ich gesehen habe, ist, einen Messenger als Mediator zu verwenden, anstatt den Service direkt in ein Viewmodel zu injizieren Der Messenger wird stattdessen in das View-Modell injiziert. Das Ansichtsmodell abonniert ein Ereignis und empfängt Ereignisse, die Modelle aus dem Ereignis enthalten. Dies ist ideal, wenn Sie regelmäßig Aktualisierungen erhalten oder Updates von mehreren Diensten erhalten, die Sie zu einem einzigen Stream zusammenführen möchten.
Die Verwendung eines Boten anstelle eines Dienstes, wenn Anfragen / Anfragen bearbeitet werden, macht keinen Sinn, da Sie dafür mehr Code schreiben müssen, den Sie schreiben müssten, wenn Sie den Dienst einfach einfügen direkt und es macht den Code schwer zu lesen.
Betrachten Sie Ihren Code oben. Stellen Sie sich vor, Sie müssten für jede Methode ein Ereignis schreiben (Navigate, CanNavigate, GoBack, GoForward usw.). Sie würden mit einer Menge Nachrichten enden. Ihr Code wäre auch schwieriger zu folgen.
Tags und Links mvvm mvvm-light messaging