Freigeben über

Migrieren von MvvmLight

  • Artikel

In diesem Artikel werden einige der wichtigsten Unterschiede zwischen dem MvvmLight-Toolkit und dem MVVM-Toolkit beschrieben, um Ihre Migration zu vereinfachen.

Während sich dieser Artikel speziell auf die Migrationen von MvvmLight zum MVVM Toolkit konzentriert, beachten Sie, dass es zusätzliche Verbesserungen gibt, die im MVVM-Toolkit vorgenommen wurden, daher empfiehlt es sich dringend, sich die Dokumentation für die einzelnen neuen APIs anzusehen.

Plattform-APIs:ObservableObject, ObservableRecipient, RelayCommand, RelayCommand<T>, AsyncRelayCommand, AsyncRelayCommand<T>, IMessenger, WeakReferenceMessenger, StrongReferenceMessenger, IRecipient<TMessage>, MessageHandler<TRecipient, TMessage>, IMessengerExtensions

Installieren des MVVM-Toolkits

Um das MVVM-Toolkit nutzen zu können, müssen Sie zuerst das neueste NuGet-Paket in Ihrer vorhandenen .NET-Anwendung installieren.

Installieren über .NET CLI

dotnet add package CommunityToolkit.Mvvm --version 8.1.0

Installieren über PackageReference

<PackageReference Include="CommunityToolkit.Mvvm" Version="8.1.0" />

Migrieren von ObservableObject

Die folgenden Schritte konzentrieren sich auf die Migration Ihrer vorhandenen Komponenten, die das ObservableObject des MvvmLight Toolkits nutzen. Das MVVM-Toolkit stellt einen ObservableObject ähnlichen Typ bereit.

Die erste Änderung hier wird mithilfe von Direktiven in Ihren Komponenten ausgetauscht.

// MvvmLight
using GalaSoft.MvvmLight;

// MVVM Toolkit
using CommunityToolkit.Mvvm.ComponentModel;

Nachfolgend finden Sie eine Liste der Migrationen, die ausgeführt werden müssen, wenn sie in Ihrer aktuellen Lösung verwendet werden.

ObservableObject-Methoden

Set<T>(Expression, ref T, T)

Set(Expression, ref T, T) verfügt über keinen gleichwertigen Methodensignaturersatz.

SetProperty(ref T, T, string) bietet jedoch die gleiche Funktionalität mit zusätzlichen Leistungsvorteilen.

// MvvmLight
Set(() => MyProperty, ref this.myProperty, value);

// MVVM Toolkit
SetProperty(ref this.myProperty, value);

Beachten Sie, dass der string-Parameter nicht erforderlich ist, wenn die Methode vom Setter der Eigenschaft aufgerufen wird, da er aus dem Namen des aufrufenden Mitglieds abgeleitet wird, wie hier zu sehen ist. Wenn Sie SetProperty aufrufen möchten, die sich von der Eigenschaft unterscheidet, in der die Methode aufgerufen wird, können Sie dies mithilfe des nameof-Operators tun, was hilfreich sein kann, um den Code weniger fehleranfällig zu machen, indem sie keine hartcodierten Namen haben. Beispiel:

SetProperty(ref this.someProperty, value, nameof(SomeProperty));

Set<T>(string, ref T, T)

Set<T>(string, ref T, T) verfügt über keinen gleichwertigen Methodensignaturersatz.

SetProperty<T>(ref T, T, string) stellt jedoch die gleiche Funktionalität mit erneut sortierten Parametern bereit.

// MvvmLight
Set(nameof(MyProperty), ref this.myProperty, value);

// MVVM Toolkit
SetProperty(ref this.myProperty, value);

Set<T>(ref T, T, string)

Set<T>(ref T, T, string) hat einen umbenannten direkten Ersatz, SetProperty<T>(ref T, T, string).

// MvvmLight
Set(ref this.myProperty, value, nameof(MyProperty));

// MVVM Toolkit
SetProperty(ref this.myProperty, value);

RaisePropertyChanged(string)

RaisePropertyChanged(string) hat einen umbenannten direkten Ersatz, OnPropertyChanged(string).

// MvvmLight
RaisePropertyChanged(nameof(MyProperty));

// MVVM Toolkit
OnPropertyChanged();

Wie bei SetProperty wird der Name der aktuellen Eigenschaft automatisch von der OnPropertyChanged-Methode abgeleitet. Wenn Sie diese Methode verwenden möchten, um das PropertyChanged-Ereignis für eine andere Eigenschaft manuell auszuheben, können Sie auch manuell den Namen dieser Eigenschaft angeben, indem Sie den nameof-Operator erneut verwenden. Beispiel:

OnPropertyChanged(nameof(SomeProperty));

RaisePropertyChanged<T>(Expression)

RaisePropertyChanged<T>(Expression) verfügt nicht über einen direkten Ersatz.

Es wird empfohlen, die Leistung zu verbessern, die Sie stattdessen RaisePropertyChanged<T>(Expression) durch das Toolkit OnPropertyChanged(string) mit dem nameof-Schlüsselwort ersetzen (oder ohne Parameter, wenn die Zieleigenschaft mit der Methode identisch ist, die die Methode aufruft, sodass der Name automatisch wie oben erwähnt abgeleitet werden kann).

// MvvmLight
RaisePropertyChanged(() => MyProperty);

// MVVM Toolkit
OnPropertyChanged(nameof(MyProperty));

VerifyPropertyName(string)

Es gibt keinen direkten Ersatz für die VerifyPropertyName(string)-Methode, und jeder Code, der dies verwendet, sollte geändert oder entfernt werden.

Der Grund für die Auslassung des MVVM-Toolkits besteht darin, dass die Verwendung des nameof-Schlüsselworts für eine Eigenschaft überprüft, ob es vorhanden ist. Beim Erstellen von MvvmLight war das nameof-Schlüsselwort nicht verfügbar, und diese Methode wurde verwendet, um sicherzustellen, dass die Eigenschaft für das Objekt vorhanden ist.

// MvvmLight
VerifyPropertyName(nameof(MyProperty));

// MVVM Toolkit
// No direct replacement, remove

ObservableObject-Eigenschaften

PropertyChangedHandler

PropertyChangedHandler verfügt nicht über einen direkten Ersatz.

Zum Auslösen eines Eigenschaftsänderungsereignisses über den PropertyChanged-Ereignishandler müssen Sie stattdessen die OnPropertyChanged-Methode aufrufen.

// MvvmLight
PropertyChangedEventHandler handler = PropertyChangedHandler;

// MVVM Toolkit
OnPropertyChanged();

Migrieren von ViewModelBase

Die folgenden Schritte konzentrieren sich auf die Migration Ihrer vorhandenen Komponenten, die das ViewModelBase-MvvmLight Toolkit nutzen.

Das MVVM-Toolkit stellt einen ObservableRecipient-Typ bereit, der ähnliche Funktionen bereitstellt.

Nachfolgend finden Sie eine Liste der Migrationen, die ausgeführt werden müssen, wenn sie in Ihrer aktuellen Lösung verwendet werden.

ViewModelBase-Methoden

Set<T>(string, ref T, T, bool)

Set<T>(string, ref T, T, bool) verfügt über keinen gleichwertigen Methodensignaturersatz.

SetProperty<T>(ref T, T, bool, string) stellt jedoch die gleiche Funktionalität mit erneut sortierten Parametern bereit.

// MvvmLight
Set(nameof(MyProperty), ref this.myProperty, value, true);

// MVVM Toolkit
SetProperty(ref this.myProperty, value, true);

Beachten Sie, dass der Wert und die Übertragung boolescher Parameter in der Implementierung des MVVM-Toolkits nicht optional sind und zur Verwendung dieser Methode bereitgestellt werden müssen. Der Grund für diese Änderung ist, dass durch Weglassen des Übertragungsparameters beim Aufrufen dieser Methode standardmäßig die ObservableObject-Methode SetProperty aufgerufen wird.

Außerdem ist der string-Parameter nicht erforderlich, wenn die Methode vom Setter der Eigenschaft aufgerufen wird, da sie vom Namen des Aufrufers member abgeleitet wird, genau wie bei den Methoden in der Basisklasse ObservableObject.

Set<T>(ref T, T, bool, string)

Set<T>(ref T, T, bool, string) hat einen umbenannten direkten Ersatz, SetProperty<T>(ref T, T, bool, string).

// MvvmLight
Set(ref this.myProperty, value, true, nameof(MyProperty));

// MVVM Toolkit
SetProperty(ref this.myProperty, value, true);

Set<T>(Expression, ref T, T, bool)

Set<T>(Expression, ref T, T, bool) verfügt nicht über einen direkten Ersatz.

Es wird empfohlen, die Leistung zu verbessern, indem Sie dies durch das MVVM-Toolkit SetProperty<T>(ref T, T, bool, string) ersetzen, indem Sie stattdessen das nameof-Schlüsselwort verwenden.

// MvvmLight
Set<MyObject>(() => MyProperty, ref this.myProperty, value, true);

// MVVM Toolkit
SetProperty(ref this.myProperty, value, true);

Broadcast<T>(T, T, string)

Broadcast<T>(T, T, string) verfügt über einen direkten Ersatz, der keine Umbenennung erfordert.

// MvvmLight
Broadcast<MyObject>(oldValue, newValue, nameof(MyProperty));

// MVVM Toolkit
Broadcast(oldValue, newValue, nameof(MyProperty));

Beachten Sie, dass die über die Messenger-Eigenschaft gesendete Nachricht beim Aufrufen der Broadcast-Methode einen direkten Ersatz für PropertyChangedMessage die MVVM-Toolkit-Bibliothek aufweist.

RaisePropertyChanged<T>(string, T, T, bool)

Es gibt keinen direkten Ersatz für die RaisePropertyChanged<T>(string, T, T, bool)-Methode.

Die einfachste Alternative besteht darin, OnPropertyChanged und dann Broadcast aufzurufen, um diese Funktionalität zu erreichen.

// MvvmLight
RaisePropertyChanged<MyObject>(nameof(MyProperty), oldValue, newValue, true);

// MVVM Toolkit
OnPropertyChanged();
Broadcast(oldValue, newValue, nameof(MyProperty));

RaisePropertyChanged<T>(Expression, T, T, bool)

Es gibt keinen direkten Ersatz für die RaisePropertyChanged<T>(Expression, T, T, bool)-Methode.

Die einfachste Alternative besteht darin, OnPropertyChanged und dann Broadcast aufzurufen, um diese Funktionalität zu erreichen.

// MvvmLight
RaisePropertyChanged<MyObject>(() => MyProperty, oldValue, newValue, true);

// MVVM Toolkit
OnPropertyChanged(nameof(MyProperty));
Broadcast(oldValue, newValue, nameof(MyProperty));

ICleanup.Cleanup()

Es gibt keinen direkten Ersatz für die ICleanup-Schnittstelle.

ObservableRecipient stellt jedoch eine OnDeactivated-Methode bereit, die verwendet werden sollte, um die gleiche Funktionalität wie Cleanup bereitzustellen.

OnDeactivated im MVVM Toolkit wird auch die Registrierung aller registrierten Messenger-Ereignisse aufheben, wenn sie aufgerufen werden.

// MvvmLight
Cleanup();

// MVVM Toolkit
OnDeactivated();

Beachten Sie, dass die OnActivated-Methoden und OnDeactivated-Methoden wie bei Cleanup der vorhandenen Lösung aufgerufen werden können.

ObservableRecipient macht jedoch eine IsActive-Eigenschaft verfügbar, die auch den Aufruf dieser Methoden steuert, wenn sie festgelegt wird.

ViewModelBase-Eigenschaften

MessengerInstance

MessengerInstance hat einen umbenannten direkten Ersatz, Messenger.

// MvvmLight
IMessenger messenger = MessengerInstance;

// MVVM Toolkit
IMessenger messenger = Messenger;

Hinweis

Der Standardwert der Messenger-Eigenschaft ist die WeakReferenceMessenger.Default-Instanz, bei der es sich um die standardmäßige schwache Referenz-Messenger-Implementierung im MVVM-Toolkit handelt. Dies kann angepasst werden, indem einfach eine andere IMessenger-Instanz in den ObservableRecipient-Konstruktor eingefügt wird.

IsInDesignMode

Es gibt keinen direkten Ersatz für die IsInDesignMode-Eigenschaft, und jeder Code, der diese verwendet, sollte geändert oder entfernt werden.

Der Grund für die Auslassung des MVVM-Toolkits besteht darin, dass die IsInDesignMode-Eigenschaft plattformspezifische Implementierungen verfügbar gemacht hat. Das MVVM Toolkit wurde entwickelt, um plattformunabhängig zu sein.

// MvvmLight
var isInDesignMode = IsInDesignMode;

// MVVM Toolkit
// No direct replacement, remove

Statische Eigenschaften von ViewModelBase

IsInDesignModeStatic

Es gibt keinen direkten Ersatz für die IsInDesignModeStatic-Eigenschaft, und jeder Code, der diese verwendet, sollte geändert oder entfernt werden.

Der Grund für die Auslassung des MVVM-Toolkits besteht darin, dass die IsInDesignMode-Eigenschaft plattformspezifische Implementierungen verfügbar gemacht hat. Das MVVM Toolkit wurde entwickelt, um plattformunabhängig zu sein.

// MvvmLight
var isInDesignMode = ViewModelBase.IsInDesignModeStatic;

// MVVM Toolkit
// No direct replacement, remove

Migrieren von RelayCommand

Die folgenden Schritte konzentrieren sich auf die Migration Ihrer vorhandenen Komponenten, die das RelayCommand-MvvmLight Toolkit nutzen.

Das MVVM-Toolkit bietet einen RelayCommand-Typ, der ähnliche Funktionen bereitstellt, die die ICommand-Systemschnittstelle nutzen.

Nachfolgend finden Sie eine Liste der Migrationen, die ausgeführt werden müssen, wenn sie in Ihrer aktuellen Lösung verwendet werden. Wenn eine Methode oder Eigenschaft nicht aufgeführt ist, gibt es eine direkte Ersetzung mit demselben Namen im MVVM-Toolkit und es ist keine Änderung erforderlich.

Die erste Änderung hier wird mithilfe von Direktiven in Ihren Komponenten ausgetauscht.

// MvvmLight
using GalaSoft.MvvmLight.Command;
using Galasoft.MvvmLight.CommandWpf;

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Hinweis

MvvmLight verwendet schwache Verweise, um die Verknüpfung zwischen dem Befehl und der Aktion herzustellen, die von der zugeordneten Klasse aufgerufen wird. Dies ist von der MVVM-Toolkit-Implementierung nicht erforderlich, und wenn dieser optionale Parameter in einem Ihrer Konstruktoren auf true festgelegt wurde, wird dies entfernt.

Verwenden von RelayCommand mit asynchronen Aktionen

Wenn Sie derzeit die MvvmLight-Implementierung RelayCommand mit asynchronen Aktionen verwenden, macht das MVVM-Toolkit eine verbesserte Implementierung für diese Szenarien verfügbar.

Sie können Ihre vorhandene RelayCommand einfach durch das vorhandene AsyncRelayCommand ersetzen, das für asynchrone Zwecke erstellt wurde.

// MvvmLight
var command = new RelayCommand(() => OnCommandAsync());
var command = new RelayCommand(async () => await OnCommandAsync());

// MVVM Toolkit
var asyncCommand = new AsyncRelayCommand(OnCommandAsync);

RelayCommand-Methoden

RaiseCanExecuteChanged()

Die Funktionalität RaiseCanExecuteChanged() kann mit der Methode NotifyCanExecuteChanged() des MVVM Toolkits erreicht werden.

// MvvmLight
var command = new RelayCommand(OnCommand);
command.RaiseCanExecuteChanged();

// MVVM Toolkit
var command = new RelayCommand(OnCommand);
command.NotifyCanExecuteChanged();

Migrieren von RelayCommand<T>

Die folgenden Schritte konzentrieren sich auf die Migration Ihrer vorhandenen Komponenten, die das RelayCommand<T>-MvvmLight Toolkit nutzen.

Das MVVM-Toolkit bietet einen RelayCommand<T>-Typ, der ähnliche Funktionen bereitstellt, die die ICommand-Systemschnittstelle nutzt.

Nachfolgend finden Sie eine Liste der Migrationen, die ausgeführt werden müssen, wenn sie in Ihrer aktuellen Lösung verwendet werden. Wenn eine Methode oder Eigenschaft nicht aufgeführt ist, gibt es eine direkte Ersetzung mit demselben Namen im MVVM-Toolkit und es ist keine Änderung erforderlich.

Die erste Änderung hier wird mithilfe von Direktiven in Ihren Komponenten ausgetauscht.

// MvvmLight
using GalaSoft.MvvmLight.Command;
using Galasoft.MvvmLight.CommandWpf;

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Verwenden von RelayCommand mit asynchronen Aktionen

Wenn Sie derzeit die MvvmLight-Implementierung RelayCommand<T> mit asynchronen Aktionen verwenden, macht das MVVM-Toolkit eine verbesserte Implementierung für diese Szenarien verfügbar.

Sie können Ihre vorhandene RelayCommand<T> einfach durch das vorhandene AsyncRelayCommand<T> ersetzen, das für asynchrone Zwecke erstellt wurde.

// MvvmLight
var command = new RelayCommand<string>(async () => await OnCommandAsync());

// MVVM Toolkit
var asyncCommand = new AsyncRelayCommand<string>(OnCommandAsync);

RelayCommand<T> Methoden

RaiseCanExecuteChanged()

Die Funktionalität RaiseCanExecuteChanged() kann mit der Methode NotifyCanExecuteChanged() des MVVM Toolkits erreicht werden.

// MvvmLight
var command = new RelayCommand<string>(OnCommand);
command.RaiseCanExecuteChanged();

// MVVM Toolkit
var command = new RelayCommand<string>(OnCommand);
command.NotifyCanExecuteChanged();

Migrieren von SimpleIoc

Die IoC-Implementierung im MVVM-Toolkit enthält keine integrierte Logik zum Verarbeiten von Abhängigkeitseinfügungen selbst, sodass Sie eine beliebige Drittanbieterbibliothek verwenden können, um eine IServiceProvider-Instanz abzurufen, die Sie dann an die Ioc.ConfigureServices-Methode übergeben können. In den folgenden Beispielen wird der ServiceCollection-Typ aus der Microsoft.Extensions.DependencyInjection-Bibliothek verwendet.

Dies ist die größte Änderung zwischen MvvmLight und dem MVVM Toolkit.

Diese Implementierung fühlt sich vertraut an, wenn Sie die Abhängigkeitsinjektion mit ASP.NET Core-Anwendungen implementiert haben.

Registrieren Ihrer Abhängigkeiten

Bei MvvmLight haben Sie möglicherweise Ihre Abhängigkeiten registriert, die diesen Szenarien mit SimpleIoc ähneln.

public void RegisterServices()
{
  SimpleIoc.Default.Register<INavigationService, NavigationService>();

  SimpleIoc.Default.Register<IDialogService>(() => new DialogService());
}

Mit dem MVVM Toolkit würden Sie dasselbe wie folgt erreichen.

public void RegisterServices()
{
  Ioc.Default.ConfigureServices(
    new ServiceCollection()
    .AddSingleton<INavigationService, NavigationService>()
    .AddSingleton<IDialogService>(new DialogService())
    .BuildServiceProvider());
}

Auflösen von Abhängigkeiten

Nach der Initialisierung können Dienste aus der Ioc-Klasse mit SimpleIoc abgerufen werden:

IDialogService dialogService = SimpleIoc.Default.GetInstance<IDialogService>();

Die Migration zum MVVM-Toolkit erfolgt wie folgt:

IDialogService dialogService = Ioc.Default.GetService<IDialogService>();

Abhängigkeiten entfernen

Mit SimpleIoc würden Sie die Registrierung Ihrer Abhängigkeiten mit dem folgenden Methodenaufruf aufheben.

SimpleIoc.Default.Unregister<INavigationService>();

Es gibt keinen direkten Ersatz für das Entfernen von Abhängigkeiten mit der MVVM-Toolkit-Implementierung Ioc.

Bevorzugter Konstruktor

Beim Registrieren Ihrer Abhängigkeiten bei MvvmLights SimpleIoc haben Sie die Möglichkeit in Ihren Klassen, ein PreferredConstructor-Attribut für Personen mit mehreren Konstruktoren bereitzustellen.

Dieses Attribut muss entfernt werden, wo er verwendet wird, und Sie müssen alle Attribute aus der verwendeten Abhängigkeitsinjektionsbibliothek des Drittanbieters verwenden, falls unterstützt.

Migrieren von Messenger

Die folgenden Schritte konzentrieren sich auf die Migration Ihrer vorhandenen Komponenten, die das Messenger-MvvmLight Toolkit nutzen.

Das MVVM-Toolkit bietet zwei Messenger-Implementierungen (WeakReferenceMessenger und StrongReferenceMessenger, siehe Dokumente hier), die ähnliche Funktionen bieten, mit einigen wichtigen Unterschieden unten.

Nachfolgend finden Sie eine Liste der Migrationen, die ausgeführt werden müssen, wenn sie in Ihrer aktuellen Lösung verwendet werden.

Die erste Änderung hier wird mithilfe von Direktiven in Ihren Komponenten ausgetauscht.

// MvvmLight
using GalaSoft.MvvmLight.Messaging;

// MVVM Toolkit
using CommunityToolkit.Mvvm.Messaging;

Messenger-Methoden

Register<TMessage>(object, Action<TMessage>)

Die Funktionalität Register<TMessage>(object, Action<TMessage>) kann mit der Erweiterungsmethode Register<TRecipient, TMessage>(object, MessageHandler<TRecipient, TMessage>) des IMessenger-MVVM-Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Register<MyMessage>(this, this.OnMyMessageReceived);

// MVVM Toolkit
Messenger.Register<MyViewModel, MyMessage>(this, static (r, m) => r.OnMyMessageReceived(m));

Der Grund für diese Signatur ist, dass es dem Messenger ermöglicht, schwache Verweise zu verwenden, um Empfänger ordnungsgemäß zu verfolgen und zu vermeiden, dass Schließungen zum Erfassen des Empfängers selbst erstellt werden. Das heißt, der Eingabeempfänger wird als Eingabe an den Lambda-Ausdruck übergeben, sodass er nicht vom Lambda-Ausdruck selbst erfasst werden muss. Dies führt auch zu effizienteren Code, da derselbe Handler mehrmals ohne Zuordnungen wiederverwendet werden kann. Beachten Sie, dass dies nur eine der unterstützten Methoden zum Registrieren von Handlern ist, und es ist auch möglich, stattdessen die IRecipient<TMessage>-Schnittstelle zu verwenden (detailliert in den Messenger-Dokumenten), wodurch die Registrierung automatisch und weniger ausführlich wird.

Hinweis

Der static-Modifizierer für Lambda-Ausdrücke erfordert C# 9 und ist optional. Es ist nützlich, es hier zu verwenden, um sicherzustellen, dass Sie nicht versehentlich den Empfänger oder ein anderes Mitglied erfassen, was die Zuweisung einer Schließung verursacht, aber nicht obligatorisch ist. Wenn Sie C# 9 nicht verwenden können, können Sie static einfach hier entfernen und nur vorsichtig sein, um sicherzustellen, dass der Code nichts erfasst.

Darüber hinaus verwendet dieses Beispiel und die unten aufgeführten nur die Messenger-Eigenschaft von ObservableRecipient. Wenn Sie nur von überall aus in Ihrem Code auf eine Messenger-Instanz zugreifen möchten, gelten die gleichen Beispiele auch, wobei der einzige Unterschied besteht, dass Messenger durch z. B. WeakReferenceMessenger.Default ersetzt werden muss.

Register<TMessage>(object, bool, Action<TMessage>)

Es gibt keinen direkten Ersatz für diesen Registrierungsmechanismus, mit dem Sie auch den Empfang von Nachrichten für abgeleitete Nachrichtentypen unterstützen können. Diese Änderung ist beabsichtigt, da die Messenger-Umsetzung darauf abzielt, keine Reflexion zu verwenden, um ihre Leistungsvorteile zu erzielen.

Alternativ gibt es einige Optionen, mit denen diese Funktionalität erreicht werden kann.

  • Eine benutzerdefinierte IMessenger-Implementierung erstellen.
  • Registrieren Sie die zusätzlichen Nachrichtentypen mithilfe eines freigegebenen Handlers, als den Typ zu überprüfen und die richtige Methode aufzurufen.
// MvvmLight
Messenger.Default.Register<MyMessage>(this, true, this.OnMyMessageReceived);

// MVVM Toolkit
Messenger.Register<MyViewModel, MyMessage>(this, static (r, m) => r.OnMyMessageReceived(m));
Messenger.Register<MyViewModel, MyOtherMessage>(this, static (r, m) => r.OnMyMessageReceived(m));

Register<TMessage>(object, object, Action<TMessage>)

Die Funktionalität Register<TMessage>(object, object, Action<TMessage>) kann mit der Methode des Register<TRecipient, TMessage, TToken>(object, TToken, MessageHandler<TRecipient, TMessage>)-MVVM Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Register<MyMessage>(this, nameof(MyViewModel), this.OnMyMessageReceived);

// MVVM Toolkit
Messenger.Register<MyViewModel, MyMessage, string>(this, nameof(MyViewModel), static (r, m) => r.OnMyMessageReceived(m));

Register<TMessage>(object, object, bool, Action<TMessage>)

Es gibt keinen direkten Ersatz für diesen Registrierungsmechanismus, mit dem Sie auch den Empfang von Nachrichten für abgeleitete Nachrichtentypen unterstützen können. Diese Änderung ist beabsichtigt, da die Messenger-Umsetzung darauf abzielt, keine Reflexion zu verwenden, um ihre Leistungsvorteile zu erzielen.

Alternativ gibt es einige Optionen, mit denen diese Funktionalität erreicht werden kann.

  • Eine benutzerdefinierte IMessenger-Implementierung erstellen.
  • Registrieren Sie die zusätzlichen Nachrichtentypen mithilfe eines freigegebenen Handlers, als den Typ zu überprüfen und die richtige Methode aufzurufen.
// MvvmLight
Messenger.Default.Register<MyMessage>(this, nameof(MyViewModel), true, this.OnMyMessageReceived);

// MVVM Toolkit
Messenger.Register<MyViewModel, MyMessage, string>(this, nameof(MyViewModel), static (r, m) => r.OnMyMessageReceived(m));
Messenger.Register<MyViewModel, MyOtherMessage, string>(this, nameof(MyViewModel), static (r, m) => r.OnMyMessageReceived(m));

Send<TMessage>(TMessage)

Die Funktionalität Send<TMessage>(TMessage) kann mit der Erweiterungsmethode Send<TMessage>(TMessage) des IMessenger-MVVM-Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Send<MyMessage>(new MyMessage());
Messenger.Default.Send(new MyMessage());

// MVVM Toolkit
Messenger.Send(new MyMessage());

Im obigen Szenario, in dem die gesendete Nachricht über einen parameterlosen Konstruktor verfügt, verfügt das MVVM-Toolkit über eine vereinfachte Erweiterung zum Senden einer Nachricht in diesem Format.

// MVVM Toolkit
Messenger.Send<MyMessage>();

Send<TMessage>(TMessage, object)

Die Funktionalität Send<TMessage>(TMessage, object) kann mit der Methode des Send<TMessage, TToken>(TMessage, TToken)-MVVM Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Send<MyMessage>(new MyMessage(), nameof(MyViewModel));
Messenger.Default.Send(new MyMessage(), nameof(MyViewModel));

// MVVM Toolkit
Messenger.Send(new MyMessage(), nameof(MyViewModel));

Unregister(object)

Die Funktionalität Unregister(object) kann mit der Methode des UnregisterAll(object)-MVVM Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Unregister(this);

// MVVM Toolkit
Messenger.UnregisterAll(this);

Unregister<TMessage>(object)

Die Funktionalität Unregister<TMessage>(object) kann mit der Erweiterungsmethode Unregister<TMessage>(object) des IMessenger-MVVM-Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Unregister<MyMessage>(this);

// MVVM Toolkit
Messenger.Unregister<MyMessage>(this);

Unregister<TMessage>(object, Action<TMessage>)

Es gibt keinen direkten Ersatz für die Unregister<TMessage>(object, Action<TMessage>)-Methode im MVVM-Toolkit.

Der Grund für die Auslassung ist, dass ein Nachrichtenempfänger nur einen einzigen registrierten Handler für jeden bestimmten Nachrichtentyp haben kann.

Wir empfehlen, diese Funktionalität mit der Erweiterungsmethode Unregister<TMessage>(object) des MVVM-Toolkits IMessenger zu erreichen.

// MvvmLight
Messenger.Default.Unregister<MyMessage>(this, OnMyMessageReceived);

// MVVM Toolkit
Messenger.Unregister<MyMessage>(this);

Unregister<TMessage>(object, object)

Die Funktionalität Unregister<TMessage>(object, object) kann mit der Methode des Unregister<TMessage, TToken>(object, TToken)-MVVM Toolkits erreicht werden.

// MvvmLight
Messenger.Default.Unregister<MyMessage>(this, nameof(MyViewModel));

// MVVM Toolkit
Messenger.Unregister<MyMessage, string>(this, nameof(MyViewModel));

Unregister<TMessage>(object, object, Action<TMessage>)

Es gibt keinen direkten Ersatz für die Unregister<TMessage>(object, object, Action<TMessage>)-Methode im MVVM-Toolkit.

Der Grund für die Auslassung ist, dass ein Nachrichtenempfänger nur einen einzigen registrierten Handler für jeden bestimmten Nachrichtentyp haben kann.

Wir empfehlen, diese Funktionalität mit der Methode des MVVM-Toolkits Unregister<TMessage, TToken>(object, TToken) zu erreichen.

// MvvmLight
Messenger.Default.Unregister<MyMessage>(this, nameof(MyViewModel), OnMyMessageReceived);

// MVVM Toolkit
Messenger.Unregister<MyMessage, string>(this, nameof(MyViewModel));

Cleanup()

Die Cleanup-Methode verfügt über einen direkten Ersatz mit demselben Namen im MVVM-Toolkit. Beachten Sie, dass diese Methode nur nützlich ist, wenn ein Messenger mit schwachen Verweisen verwendet wird, während der StrongReferenceMessenger-Typ einfach nichts tut, wenn diese Methode aufgerufen wird, da der interne Zustand bereits automatisch gekürzt wird, während der Messenger verwendet wird.

// MvvmLight
Messenger.Default.Cleanup();

// MVVM Toolkit
Messenger.Cleanup();

RequestCleanup()

Es gibt keinen direkten Ersatz für die RequestCleanup-Methode im MVVM-Toolkit. Im Kontext von MvvmLight wird RequestCleanup verwendet, um eine Anforderung zum Entfernen von Registrierungen zu initiieren, die nicht mehr aktiv sind, da die Implementierung schwache Verweise nutzt.

Alle Aufrufe der RequestCleanup-Methode können entfernt oder durch Cleanup ersetzt werden.

// MvvmLight
Messenger.Default.RequestCleanup();

// MVVM Toolkit
// No direct replacement, remove

ResetAll()

Die Funktionalität ResetAll() kann mit der Methode des Reset()-MVVM Toolkits erreicht werden.

Im Gegensatz zur Implementierung von MvvmLight, die die Instanz nulliert, löscht das MVVM-Toolkit die registrierten Karten.

// MvvmLight
Messenger.Default.ResetAll();

// MVVM Toolkit
Messenger.Reset();

Statische Messenger-Methoden

OverrideDefault(IMessenger)

Es gibt keinen direkten Ersatz für die OverrideDefault(IMessenger)-Methode im MVVM-Toolkit.

Um eine benutzerdefinierte Implementierung des IMessenger-Diensts zu verwenden, registrierten Sie entweder die benutzerdefinierte Implementierung in den Dienstregistrierungen für abhängigkeitseinfügungen, oder erstellen Sie manuell eine statische Instanz, und übergeben Sie dies bei Bedarf.

// MvvmLight
Messenger.OverrideDefault(new Messenger());

// MVVM Toolkit
// No direct replacement

Reset()

Es gibt keinen direkten Ersatz für die statische Reset-Methode im MVVM-Toolkit.

Die gleiche Funktionalität kann durch Aufrufen der Reset-Methode der statischen Default-Instanz eines der Messenger-Typen erreicht werden.

// MvvmLight
Messenger.Reset();

// MVVM Toolkit
WeakReferenceMessenger.Default.Reset();

Statische Messenger-Eigenschaften

Default

Default verfügt über einen direkten Ersatz, Default, der keine Änderung an Ihrer vorhandenen Implementierung erfordert.

// MvvmLight
IMessenger messenger = Messenger.Default;

// MVVM Toolkit
IMessenger messenger = WeakReferenceMessenger.Default;

Migrieren von Nachrichtentypen

Die im MvvmLight-Toolkit bereitgestellten Nachrichtentypen sind als Basis für Sie als Entwickler für die Arbeit bei Bedarf konzipiert.

Während das MVVM-Toolkit einige Alternativen bereitstellt, gibt es keinen direkten Ersatz für diese Nachrichtentypen. Wir empfehlen, unsere verfügbaren Nachrichtentypen zu betrachten.

Wenn Ihre Lösung die MvvmLight-Nachrichtentypen nutzt, können diese problemlos in Ihre eigene Codebasis portiert werden.

Migrieren plattformspezifischer Komponenten

In der aktuellen MVVM Toolkit-Implementierung gibt es keine Ersatz für plattformspezifische Komponenten, die im MvvmLight-Toolkit vorhanden sind.

Die folgenden Komponenten und die zugehörigen Hilfs-/Erweiterungsmethoden verfügen nicht über einen Ersatz und müssen bei der Migration zum MVVM-Toolkit in Erwägung gezogen werden.

Android/iOS/Windows specifisch

  • DialogService
  • DispatcherHelper
  • NavigationService

Android/iOS-spezifisch

  • ActivityBase
  • Binding
  • BindingMode
  • PropertyChangedEventManager
  • UpdateTriggerMode

Android-spezifisch

  • CachingViewHolder
  • ObservableAdapter
  • ObservableRecyclerAdapter

iOS-spezifisch

  • ObservableCollectionViewSource
  • ObservableTableViewController
  • ObservableTableViewSource

Hilfsmethoden

  • Empty
  • WeakAction
  • WeakFunc