Migration à partir de MvvmLight
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