Migration à partir de MvvmLight

  • Article

Cet article décrit certaines des principales différences entre le kit de ressources MvvmLight et le kit de ressources MVVM afin de faciliter votre migration.

Bien que cet article soit axé spécifiquement sur les migrations de MvvmLight vers le kit de ressources MVVM, notez que des améliorations supplémentaires ont été apportées dans le kit de ressources MVVM. Il est donc vivement recommandé de consulter la documentation relative aux nouvelles API.

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

Installation du kit de ressources MVVM

Pour tirer parti du kit de ressources MVVM, vous devez d’abord installer le dernier package NuGet sur votre application .NET existante.

Installer via l’interface CLI .NET

dotnet add package CommunityToolkit.Mvvm --version 8.1.0

Installer via PackageReference

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

Migration d’ObservableObject

Les étapes suivantes sont axées sur la migration de vos composants existants qui tirent parti de l’ObservableObject du kit de ressources MvvmLight. Le kit de ressources MVVM fournit un type ObservableObject similaire.

La première modification ici consiste à échanger les directives using dans vos composants.

// MvvmLight
using GalaSoft.MvvmLight;

// MVVM Toolkit
using CommunityToolkit.Mvvm.ComponentModel;

Vous trouverez ci-dessous la liste des migrations qui devront être effectuées en cas d’utilisation dans votre solution actuelle.

Méthodes ObservableObject

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

Set(Expression, ref T, T) n’a pas de remplacement de signature de méthode strictement équivalent.

Toutefois, SetProperty(ref T, T, string) fournit la même fonctionnalité avec des avantages supplémentaires en termes de performances.

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

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

Notez que le paramètre string n’est pas obligatoire si la méthode est appelée à partir de la méthode setter de la propriété, car il est déduit du nom du membre appelant, comme indiqué ici. Si vous souhaitez appeler SetProperty pour une propriété différente de celle où la méthode est appelée, vous pouvez le faire à l’aide de l’opérateur nameof, ce qui peut être utile pour rendre le code moins sujet aux erreurs grâce à l’absence de noms codés en dur. Exemple :

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

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

Set<T>(string, ref T, T) n’a pas de remplacement de signature de méthode strictement équivalent.

Toutefois, SetProperty<T>(ref T, T, string) fournit la même fonctionnalité avec des paramètres réordonnés.

// 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) a un remplacement direct renommé, 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) a un remplacement direct renommé, OnPropertyChanged(string).

// MvvmLight
RaisePropertyChanged(nameof(MyProperty));

// MVVM Toolkit
OnPropertyChanged();

Comme avec SetProperty, le nom de la propriété actuelle est déduit automatiquement par la méthode OnPropertyChanged. Si vous souhaitez utiliser cette méthode pour déclencher manuellement l’événement PropertyChanged pour une autre propriété, vous pouvez également spécifier manuellement le nom de cette propriété en réutilisant l’opérateur nameof. Exemple :

OnPropertyChanged(nameof(SomeProperty));

RaisePropertyChanged<T>(Expression)

RaisePropertyChanged<T>(Expression) n’a pas de remplacement direct.

Pour améliorer les performances, nous vous recommandons de remplacer RaisePropertyChanged<T>(Expression) par le OnPropertyChanged(string) du kit de ressources à l’aide du mot clé nameof (ou sans aucun paramètre, si la propriété cible est identique à celle qui appelle la méthode, auquel cas le nom peut être déduit automatiquement comme mentionné ci-dessus).

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

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

VerifyPropertyName(string)

Il n’existe aucun remplacement direct pour la méthode VerifyPropertyName(string), et tout code l’utilisant doit être modifié ou supprimé.

La raison de son omission dans le kit de ressources MVVM est que l’utilisation du mot clé nameof pour une propriété vérifie qu’elle existe. Lorsque MvvmLight a été conçu, le mot clé nameof n’était pas disponible et cette méthode était utilisée pour vérifier que la propriété existait sur l’objet.

// MvvmLight
VerifyPropertyName(nameof(MyProperty));

// MVVM Toolkit
// No direct replacement, remove

Propriétés ObservableObject

PropertyChangedHandler

PropertyChangedHandler n’a pas de remplacement direct.

Pour déclencher un événement de modification de propriété via le gestionnaire d’événements PropertyChanged, vous devez appeler la méthode OnPropertyChanged à la place.

// MvvmLight
PropertyChangedEventHandler handler = PropertyChangedHandler;

// MVVM Toolkit
OnPropertyChanged();

Migration de ViewModelBase

Les étapes suivantes sont axées sur la migration de vos composants existants qui tirent parti du ViewModelBase du kit de ressources MvvmLight.

Le kit de ressources MVVM fournit un type ObservableRecipient qui fournit une fonctionnalité similaire.

Vous trouverez ci-dessous la liste des migrations qui devront être effectuées en cas d’utilisation dans votre solution actuelle.

Méthodes ViewModelBase

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

Set<T>(string, ref T, T, bool) n’a pas de remplacement de signature de méthode strictement équivalent.

Toutefois, SetProperty<T>(ref T, T, bool, string) fournit la même fonctionnalité avec des paramètres réordonnés.

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

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

Notez que les paramètres booléens de valeur et de diffusion ne sont pas facultatifs dans l’implémentation du kit de ressources MVVM, et doivent être fournis afin de pouvoir utiliser cette méthode. La raison de cette modification est qu’en omettant le paramètre de diffusion lors de l’appel de cette méthode, elle appelle par défaut la méthode SetProperty de l’ObservableObject.

De plus, le paramètre string n’est pas obligatoire si la méthode est appelée à partir de la méthode setter de la propriété, car il est déduit du nom du membre appelant, comme avec les méthodes de la classe de base ObservableObject.

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

Set<T>(ref T, T, bool, string) a un remplacement direct renommé, 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) n’a pas de remplacement direct.

Pour améliorer les performances, nous vous recommandons de remplacer cela par la méthode SetProperty<T>(ref T, T, bool, string) du kit de ressources MVVM en utilisant le mot clé nameof à la place.

// 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) a un remplacement direct qui n’a pas besoin d’un renommage.

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

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

Notez que le message envoyé via la propriété Messenger lors de l’appel de la méthode Broadcast a un remplacement direct pour PropertyChangedMessage dans la bibliothèque du kit de ressources MVVM.

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

Il n’existe aucun remplacement direct pour la méthode RaisePropertyChanged<T>(string, T, T, bool).

L’alternative la plus simple consiste à appeler OnPropertyChanged puis Broadcast pour obtenir cette fonctionnalité.

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

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

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

Il n’existe aucun remplacement direct pour la méthode RaisePropertyChanged<T>(Expression, T, T, bool).

L’alternative la plus simple consiste à appeler OnPropertyChanged puis Broadcast pour obtenir cette fonctionnalité.

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

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

ICleanup.Cleanup()

Il n’existe aucun remplacement direct pour l’interface ICleanup.

Toutefois, l’ObservableRecipient fournit une méthode OnDeactivated qui doit être utilisée pour fournir la même fonctionnalité que Cleanup.

OnDeactivated dans le kit de ressources MVVM annule également l’inscription de tous les événements de messenger inscrits lors de l’appel.

// MvvmLight
Cleanup();

// MVVM Toolkit
OnDeactivated();

Notez que les méthodes OnActivated et OnDeactivated peuvent être appelées à partir de votre solution existante comme avec Cleanup.

Toutefois, l’ObservableRecipient expose une propriété IsActive qui contrôle également l’appel à ces méthodes lorsqu’elle est définie.

Propriétés ViewModelBase

MessengerInstance

MessengerInstance a un remplacement direct renommé, Messenger.

// MvvmLight
IMessenger messenger = MessengerInstance;

// MVVM Toolkit
IMessenger messenger = Messenger;

Remarque

La valeur par défaut de la propriété Messenger est l’instance WeakReferenceMessenger.Default, qui est l’implémentation de messenger de référence faible standard dans le kit de ressources MVVM. Cela peut être personnalisé en injectant simplement une instance IMessenger différente dans le constructeur ObservableRecipient.

IsInDesignMode

Il n’existe aucun remplacement direct pour la propriété IsInDesignMode, et tout code l’utilisant doit être modifié ou supprimé.

La raison de son omission du kit de ressources MVVM est que la propriété IsInDesignMode expose des implémentations propres à la plateforme. Le kit de ressources MVVM a été conçu pour être indépendant de la plateforme.

// MvvmLight
var isInDesignMode = IsInDesignMode;

// MVVM Toolkit
// No direct replacement, remove

Propriétés statiques ViewModelBase

IsInDesignModeStatic

Il n’existe aucun remplacement direct pour la propriété IsInDesignModeStatic, et tout code l’utilisant doit être modifié ou supprimé.

La raison de son omission du kit de ressources MVVM est que la propriété IsInDesignMode expose des implémentations propres à la plateforme. Le kit de ressources MVVM a été conçu pour être indépendant de la plateforme.

// MvvmLight
var isInDesignMode = ViewModelBase.IsInDesignModeStatic;

// MVVM Toolkit
// No direct replacement, remove

Migration de RelayCommand

Les étapes suivantes sont axées sur la migration de vos composants existants qui tirent parti du RelayCommand du kit de ressources MvvmLight.

Le kit de ressources MVVM fournit un type RelayCommand qui fournit une fonctionnalité équivalente tirant parti de l’interface système ICommand.

Vous trouverez ci-dessous la liste des migrations qui devront être effectuées en cas d’utilisation dans votre solution actuelle. Lorsqu’une méthode ou une propriété n’est pas répertoriée, il existe un remplacement direct portant le même nom dans le kit de ressources MVVM, et aucune modification n’est requise.

La première modification ici consiste à échanger les directives using dans vos composants.

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

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Remarque

MvvmLight utilise des références faibles pour établir le lien entre la commande et l’action appelée à partir de la classe associée. Cela n’est pas requis par l’implémentation du kit de ressources MVVM, et si ce paramètre facultatif a été défini sur true dans l’un de vos constructeurs, cela sera supprimé.

Utilisation de RelayCommand avec des actions asynchrones

Si vous utilisez actuellement l’implémentation RelayCommand MvvmLight avec des actions asynchrones, le kit de ressources MVVM expose une implémentation améliorée pour ces scénarios.

Vous pouvez simplement remplacer votre RelayCommand existant par le AsyncRelayCommand qui a été créé à des fins asynchrones.

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

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

Méthodes RelayCommand

RaiseCanExecuteChanged()

La fonctionnalité de RaiseCanExecuteChanged() peut être obtenue avec la méthode NotifyCanExecuteChanged() du kit de ressources MVVM.

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

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

Migration de RelayCommand<T>

Les étapes suivantes sont axées sur la migration de vos composants existants qui tirent parti du RelayCommand<T> du kit de ressources MvvmLight.

Le kit de ressources MVVM fournit un type RelayCommand<T> qui fournit une fonctionnalité équivalente tirant parti de l’interface système ICommand.

Vous trouverez ci-dessous la liste des migrations qui devront être effectuées en cas d’utilisation dans votre solution actuelle. Lorsqu’une méthode ou une propriété n’est pas répertoriée, il existe un remplacement direct portant le même nom dans le kit de ressources MVVM, et aucune modification n’est requise.

La première modification ici consiste à échanger les directives using dans vos composants.

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

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Utilisation de RelayCommand avec des actions asynchrones

Si vous utilisez actuellement l’implémentation RelayCommand<T> MvvmLight avec des actions asynchrones, le kit de ressources MVVM expose une implémentation améliorée pour ces scénarios.

Vous pouvez simplement remplacer votre RelayCommand<T> existant par l’AsyncRelayCommand<T> qui a été créé à des fins asynchrones.

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

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

RelayCommand<T> Méthodes

RaiseCanExecuteChanged()

La fonctionnalité de RaiseCanExecuteChanged() peut être obtenue avec la méthode NotifyCanExecuteChanged() du kit de ressources MVVM.

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

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

Migration de SimpleIoc

L’implémentation IoC dans le kit de ressources MVVM n’inclut aucune logique intégrée pour gérer l’injection de dépendances par elle-même. Vous êtes donc libre d’utiliser n’importe quelle bibliothèque tierce pour récupérer une instance IServiceProvider que vous pouvez ensuite transmettre à la méthode Ioc.ConfigureServices. Dans les exemples ci-dessous, le type ServiceCollection de la bibliothèque Microsoft.Extensions.DependencyInjection sera utilisé.

Il s’agit du plus grand changement entre MvvmLight et le kit de ressources MVVM.

Cette implémentation vous paraîtra familière si vous avez déjà implémenté l’injection de dépendances avec des applications ASP.NET Core.

Inscription de vos dépendances

Avec MvvmLight, vous avez peut-être inscrit vos dépendances dans des scénarios semblables à ceux-ci à l’aide de SimpleIoc.

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

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

Avec le kit de ressources MVVM, vous obtiendriez la même chose que ce qui suit.

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

Résolution des dépendances

Une fois initialisés, les services peuvent être récupérés à partir de la classe Ioc comme ceci avec SimpleIoc :

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

La migration vers le kit de ressources MVVM vous permet d’obtenir les mêmes résultats avec :

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

Suppression des dépendances

Avec SimpleIoc, vous annuleriez l’inscription de vos dépendances avec l’appel de méthode suivant.

SimpleIoc.Default.Unregister<INavigationService>();

Il n’existe aucun remplacement direct pour la suppression des dépendances avec l’implémentation du kit de ressources MVVM Ioc.

Constructeur préféré

Lors de l’inscription de vos dépendances avec le SimpleIoc de MvvmLight, vous avez la possibilité dans vos classes de fournir un attribut PreferredConstructor pour celles ayant plusieurs constructeurs.

Cet attribut devra être supprimé là où il est utilisé, et vous devrez utiliser tous les attributs de la bibliothèque d’injection de dépendances tierce en cours d’utilisation, s’ils sont pris en charge.

Migration de Messenger

Les étapes suivantes sont axées sur la migration de vos composants existants qui tirent parti du Messenger du kit de ressources MvvmLight.

Le kit de ressources MVVM fournit deux implémentations de messenger (WeakReferenceMessenger et StrongReferenceMessenger, voir la documentation ici) qui fournissent des fonctionnalités similaires, avec quelques différences clés détaillées ci-dessous.

Vous trouverez ci-dessous la liste des migrations qui devront être effectuées en cas d’utilisation dans votre solution actuelle.

La première modification ici consiste à échanger les directives using dans vos composants.

// MvvmLight
using GalaSoft.MvvmLight.Messaging;

// MVVM Toolkit
using CommunityToolkit.Mvvm.Messaging;

Méthodes Messenger

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

La fonctionnalité de Register<TMessage>(object, Action<TMessage>) peut être obtenue avec la méthode d’extension IMessenger du kit de ressources MVVM Register<TRecipient, TMessage>(object, MessageHandler<TRecipient, TMessage>).

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

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

La raison d’être de cette signature est qu’elle permet au messenger d’utiliser des références faibles pour suivre correctement les destinataires et d’éviter de créer des fermetures pour capturer le destinataire lui-même. Autrement dit, le destinataire d’entrée est transmis en tant qu’entrée à l’expression lambda. Il n’a donc pas besoin d’être capturé par l’expression lambda elle-même. Cela accroît également l’efficacité du code, car le même gestionnaire peut être réutilisé plusieurs fois sans allocations. Notez qu’il s’agit simplement de l’une des façons prises en charge d’inscrire des gestionnaires, et il est également possible d’utiliser l’interface IRecipient<TMessage> à la place (détaillée dans la documentation de messenger), ce qui rend l’inscription automatique et moins détaillée.

Remarque

Le modificateur static pour les expressions lambda nécessite C# 9, et il est facultatif. Il est utile de l’utiliser ici pour être sûr de ne pas capturer accidentellement le destinataire ou un autre membre, ce qui provoque l’allocation d’une fermeture, mais ce n’est pas obligatoire. Si vous ne pouvez pas utiliser C# 9, vous pouvez simplement supprimer static ici et veiller à ce que le code ne capture rien.

En outre, cet exemple et ceux ci-dessous utilisent simplement la propriété Messenger à partir d’ObservableRecipient. Si vous souhaitez simplement accéder statiquement à une instance messenger à partir de n’importe où ailleurs dans votre code, les mêmes exemples s’appliquent également, la seule différence étant que Messenger doit être remplacé par exemple par WeakReferenceMessenger.Default.

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

Il n’existe aucun remplacement direct pour ce mécanisme d’inscription qui vous permet de prendre également en charge la réception de messages pour les types de messages dérivés. Ce changement est intentionnel, car l’implémentation Messenger vise à ne pas utiliser la réflexion pour procurer ses avantages en matière de performances.

Il existe également quelques actions qui peuvent être effectuées pour obtenir cette fonctionnalité.

  • Créez une implémentation IMessenger personnalisée.
  • Inscrivez les types de messages supplémentaires à l’aide d’un gestionnaire partagé qui vérifie ensuite le type et appelle la méthode appropriée.
// 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>)

La fonctionnalité de Register<TMessage>(object, object, Action<TMessage>) peut être obtenue avec la méthode Register<TRecipient, TMessage, TToken>(object, TToken, MessageHandler<TRecipient, TMessage>) du kit de ressources MVVM.

// 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>)

Il n’existe aucun remplacement direct pour ce mécanisme d’inscription qui vous permet de prendre également en charge la réception de messages pour les types de messages dérivés. Ce changement est intentionnel, car l’implémentation Messenger vise à ne pas utiliser la réflexion pour procurer ses avantages en matière de performances.

Il existe également quelques actions qui peuvent être effectuées pour obtenir cette fonctionnalité.

  • Créez une implémentation IMessenger personnalisée.
  • Inscrivez les types de messages supplémentaires à l’aide d’un gestionnaire partagé qui vérifie ensuite le type et appelle la méthode appropriée.
// 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)

La fonctionnalité de Send<TMessage>(TMessage) peut être obtenue avec la méthode d’extension IMessenger du kit de ressources MVVM Send<TMessage>(TMessage).

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

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

Dans le scénario ci-dessus où le message envoyé a un constructeur sans paramètre, le kit de ressources MVVM a une extension simplifiée pour envoyer un message dans ce format.

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

Send<TMessage>(TMessage, object)

La fonctionnalité de Send<TMessage>(TMessage, object) peut être obtenue avec la méthode Send<TMessage, TToken>(TMessage, TToken) du kit de ressources MVVM.

// 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)

La fonctionnalité de Unregister(object) peut être obtenue avec la méthode UnregisterAll(object) du kit de ressources MVVM.

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

// MVVM Toolkit
Messenger.UnregisterAll(this);

Unregister<TMessage>(object)

La fonctionnalité de Unregister<TMessage>(object) peut être obtenue avec la méthode d’extension IMessenger du kit de ressources MVVM Unregister<TMessage>(object).

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

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

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

Il n’existe aucun remplacement direct pour la méthode Unregister<TMessage>(object, Action<TMessage>) dans le kit de ressources MVVM.

La raison de cette omission est qu’un destinataire de message ne peut avoir qu’un seul gestionnaire inscrit pour tout type de message donné.

Nous vous recommandons d’obtenir cette fonctionnalité avec la méthode d’extension IMessenger du kit de ressources MVVM Unregister<TMessage>(object).

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

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

Unregister<TMessage>(object, object)

La fonctionnalité de Unregister<TMessage>(object, object) peut être obtenue avec la méthode Unregister<TMessage, TToken>(object, TToken) du kit de ressources MVVM.

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

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

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

Il n’existe aucun remplacement direct pour la méthode Unregister<TMessage>(object, object, Action<TMessage>) dans le kit de ressources MVVM.

La raison de cette omission est qu’un destinataire de message ne peut avoir qu’un seul gestionnaire inscrit pour tout type de message donné.

Nous vous recommandons d’obtenir cette fonctionnalité avec la méthode Unregister<TMessage, TToken>(object, TToken) du kit de ressources MVVM.

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

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

Cleanup()

La méthode Cleanup a un remplacement direct avec le même nom dans le kit de ressources MVVM. Notez que cette méthode est utile uniquement lorsqu’un messenger utilisant des références faibles est utilisé, tandis que le type StrongReferenceMessenger ne fait tout simplement rien lorsque cette méthode est appelée, car l’état interne est déjà supprimé automatiquement lors de l’utilisation du messenger.

// MvvmLight
Messenger.Default.Cleanup();

// MVVM Toolkit
Messenger.Cleanup();

RequestCleanup()

Il n’existe aucun remplacement direct pour la méthode RequestCleanup dans le kit de ressources MVVM. Dans le contexte de MvvmLight, RequestCleanup est utilisé pour lancer une demande de suppression des inscriptions qui ne sont plus actives, car l’implémentation tire parti des références faibles.

Tous les appels à la méthode RequestCleanup peuvent être supprimés ou remplacés par Cleanup.

// MvvmLight
Messenger.Default.RequestCleanup();

// MVVM Toolkit
// No direct replacement, remove

ResetAll()

La fonctionnalité de ResetAll() peut être obtenue avec la méthode Reset() du kit de ressources MVVM.

Contrairement à l’implémentation de MvvmLight qui annule l’instance, le kit de ressources MVVM efface les mappages inscrits.

// MvvmLight
Messenger.Default.ResetAll();

// MVVM Toolkit
Messenger.Reset();

Méthodes statiques Messenger

OverrideDefault(IMessenger)

Il n’existe aucun remplacement direct pour la méthode OverrideDefault(IMessenger) dans le kit de ressources MVVM.

Pour utiliser une implémentation personnalisée de l’IMessenger, inscrivez l’implémentation personnalisée dans les inscriptions de service pour l’injection de dépendances, ou construisez manuellement une instance statique et transmettez-la si nécessaire.

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

// MVVM Toolkit
// No direct replacement

Reset()

Il n’existe aucun remplacement direct pour la méthode statique Reset dans le kit de ressources MVVM.

La même fonctionnalité peut être obtenue en appelant la méthode Reset de l’instance Default statique de l’un des types de messenger.

// MvvmLight
Messenger.Reset();

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

Propriétés statiques Messenger

Default

Default a un remplacement direct, Default, ne nécessitant aucune modification de votre implémentation existante.

// MvvmLight
IMessenger messenger = Messenger.Default;

// MVVM Toolkit
IMessenger messenger = WeakReferenceMessenger.Default;

Migration des types de messages

Les types de messages fournis dans le kit de ressources MvvmLight sont conçus comme une base à partir de laquelle vous pouvez travailler, en votre qualité de développeur.

Bien que le kit de ressources MVVM offre certaines alternatives, il n’existe aucun remplacement direct pour ces types de messages. Nous vous recommandons de consulter nos types de messages disponibles.

En guise d’alternative, si votre solution tire parti des types de messages MvvmLight, ceux-ci peuvent facilement être portés dans votre propre codebase.

Migration de composants propres à la plateforme

Dans l’implémentation actuelle de MVVM Toolkit, il n’existe aucun remplacement pour les composants propres à la plateforme qui existent dans le kit de ressources MvvmLight.

Les composants suivants et leurs méthodes d’assistance/extension associées n’ont pas de remplacement, et ceci devra être pris en compte lors de la migration vers le kit de ressources MVVM.

Composants propres à Android/iOS/Windows

  • DialogService
  • DispatcherHelper
  • NavigationService

Composants propres à Android/iOS

  • ActivityBase
  • Binding
  • BindingMode
  • PropertyChangedEventManager
  • UpdateTriggerMode

Composants propres à Android

  • CachingViewHolder
  • ObservableAdapter
  • ObservableRecyclerAdapter

Composants propres à iOS

  • ObservableCollectionViewSource
  • ObservableTableViewController
  • ObservableTableViewSource

Programmes d’assistance

  • Empty
  • WeakAction
  • WeakFunc