Ich würde gerne wissen, dass bei der Verwendung von Prism Interaction Request Objects die Verwendung des Interaction Service Patterns vorzuziehen ist. Wie für mich sollte Interaction Service in einfachen Fällen verwendet werden, d. H. Wenn Sie ein Standard-Popup-Fenster haben und nur der Textinhalt geändert wird. Auf der anderen Seite sind Interaktionsanforderungsobjekte besser geeignet, wenn die Benutzeroberfläche komplizierter ist. Der Interaction Service ist jedoch viel einfacher zu implementieren und erfordert weniger Code. Was denkst du?
Der große Nachteil bei der Verwendung eines Interaktionsdienstes zum Anzeigen eines Meldungsfelds ist das übergeordnete Fenster - oder besser gesagt das Fehlen eines.
Welches Fenster sollten Sie als übergeordnetes Element des Meldungsfelds aus dem Ansichtsmodell oder der Serviceimplementierung bereitstellen? Wenn Sie Application.Mainwindow wählen, machen Sie eine große Annahme über das gesamte Anwendungslayout.
Die einzige Entität im Prozess, die wie die Interaktion anzeigen kann, ist die Ansicht. Ob das eine Nachrichtenbox oder In-Page-Overlay verwendet.
Es gibt wenige gültige Argumente, wenn ein Interaktionsdienst verwendet wird. Der häufig verwendete ist, dass es einfacher ist. Dies mag wahr sein, trifft jedoch auch auf viele andere Dinge zu, die nicht getan werden sollten, z. Code hinter, etc.
Ich stimme Ihnen zu, dass ein Interaktionsdienst für gängiges Interaktionsverhalten wie MessageBoxen usw. geeignet sein kann.
Meiner Meinung nach läuft es auf Klassenverantwortung hinaus. Mit anderen Worten, möchten Sie, dass das ViewModel oder die View dafür verantwortlich ist, welche Art von Interaktion stattfinden soll?
Betrachten Sie eine grundlegende Interaktionsdienstschnittstelle:
%Vor%Es ist ziemlich offensichtlich aus der Beobachtung der Schnittstelle, welche Art von Verhalten ShowMessageBox erzeugen wird. Dies gibt dem ViewModel einen gewissen Grad an Kontrolle hinsichtlich der Spezifizierung, welche Art von Interaktionsverhalten erwartet wird. Das Problem mit diesem Ansatz besteht darin, dass Ihr ViewModel nun sowohl vom IInteractionService als auch von seinen Erwartungen bezüglich des Interaktionsverhaltens abhängig ist. Dies könnte Ihr ViewModel weniger wiederverwendbar machen.
Mit Interaktionsobjekten können Sie mehr Verantwortung für das Interaktionsverhalten in der Ansicht übernehmen. Mit anderen Worten, Sie können das Verhalten und das Erscheinungsbild der Interaktion ändern, ohne das ViewModel direkt zu beeinflussen. Zum Beispiel könnte V1 der Interaktionsanfrage eine einfache MessageBox anzeigen. V2 der Interaktionsanforderung könnte ein komplexerer Dialog sein, der mehr Benutzerinteraktion erfordert als ein einfacher Knopfklick. Diese Art der Änderung des Interaktionsverhaltens kann verwaltet werden, ohne dass das ViewModel geändert werden muss. Dies kann nützlich sein, wenn ein UI-Designer an dem Projekt arbeitet, der die Option haben möchte, das Verhalten oder Erscheinungsbild einer mit einer Interaktionsanfrage verknüpften Ansicht zu ändern oder zu ändern.
Sie könnten beide Strategien verwenden, wenn Sie wollten. Mit anderen Worten, ein Interaktionsdienst für gängige Interaktionsverhalten und Interaktionsobjekte für komplexeres Verhalten.
Zusammenfassend lässt sich sagen, dass Interaction Services einfacher zu verwenden ist, aber Interaktionsobjekte können meiner Meinung nach Ihre ViewModels wiederverwendbar machen.
Tags und Links .net c# silverlight prism