Migração do MvvmLight

Este artigo apresenta algumas das principais diferenças entre o MvvmLight Toolkit e o MVVM Toolkit para facilitar a sua migração.

Embora este artigo se foque especificamente nas migrações do MvvmLight para o MVVM Toolkit, note-se que foram feitas melhorias adicionais no MVVM Toolkit, pelo que é altamente recomendável consultar a documentação das novas APIs individuais.

APIs da plataforma:ObservableObject, ObservableRecipient, RelayCommand, RelayCommand<T>, AsyncRelayCommand, AsyncRelayCommand<T>, IMessenger, WeakReferenceMessengerStrongReferenceMessengerIRecipient<TMessage>MessageHandler<TRecipient, TMessage>IMessengerExtensions

Instalação do Kit de Ferramentas MVVM

Para tirar partido do MVVM Toolkit, terá primeiro de instalar o pacote NuGet mais recente na sua aplicação .NET existente.

Instalar via CLI .NET

dotnet add package CommunityToolkit.Mvvm --version 8.1.0

Instalar através de PackageReference

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

Migração do ObservableObject

Os passos seguintes centram-se na migração dos seus componentes existentes que tiram partido de ObservableObject do MvvmLight Toolkit. O MVVM Toolkit fornece um ObservableObject tipo semelhante.

A primeira alteração aqui será trocar diretivas usando os seus componentes.

// MvvmLight
using GalaSoft.MvvmLight;

// MVVM Toolkit
using CommunityToolkit.Mvvm.ComponentModel;

Abaixo está uma lista de migrações que terão de ser realizadas caso estejam a ser usadas na sua solução atual.

Métodos ObservableObject

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

Set(Expression, ref T, T) não tem substituição de assinatura de método semelhante.

No entanto, SetProperty(ref T, T, string) oferece a mesma funcionalidade com benefícios adicionais de desempenho.

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

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

Note-se que o string parâmetro não é necessário se o método for chamado a partir do setter da propriedade, pois é inferido pelo nome do membro do chamador, como pode ser visto aqui. Se quiser invocar SetProperty uma propriedade diferente daquela onde o método está a ser invocado, pode fazê-lo usando o nameof operador, o que pode ser útil para tornar o código menos propenso a erros ao não ter nomes codificados fixamente. Por exemplo:

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

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

Set<T>(string, ref T, T) não tem substituição de assinatura de método semelhante.

No entanto, SetProperty<T>(ref T, T, string) fornece a mesma funcionalidade com parâmetros reordenados.

// 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) tem um substituto direto renomeado, 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) tem um substituto direto renomeado, OnPropertyChanged(string).

// MvvmLight
RaisePropertyChanged(nameof(MyProperty));

// MVVM Toolkit
OnPropertyChanged();

Tal como com SetProperty, o nome da propriedade corrente é automaticamente inferido pelo OnPropertyChanged método. Se quiseres usar este método para criar manualmente o PropertyChanged evento para outra propriedade, também podes especificar manualmente o nome dessa propriedade usando novamente o nameof operador. Por exemplo:

OnPropertyChanged(nameof(SomeProperty));

RaisePropertyChanged<T>(Expression)

RaisePropertyChanged<T>(Expression) não tem um substituto direto.

Recomenda-se, para melhorar o desempenho, substituir RaisePropertyChanged<T>(Expression) pelo OnPropertyChanged(string) do Toolkit, utilizando a palavra-chave nameof (ou sem parâmetros, se a propriedade de destino for a mesma que invoca o método, para que o nome possa ser inferido automaticamente, como mencionado acima).

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

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

VerifyPropertyName(string)

Não existe substituto direto para o VerifyPropertyName(string) método e qualquer código que o utilize deve ser alterado ou removido.

A razão para a omissão do MVVM Toolkit é que usar a nameof palavra-chave para uma propriedade verifica a sua existência. Quando o MvvmLight foi construído, a nameof palavra-chave não estava disponível e este método foi usado para garantir que a propriedade existia no objeto.

// MvvmLight
VerifyPropertyName(nameof(MyProperty));

// MVVM Toolkit
// No direct replacement, remove

Propriedades do ObservableObject

PropertyChangedHandler

PropertyChangedHandler não tem um substituto direto.

Para despoletar um evento de alteração da propriedade através do processador de eventos PropertyChanged, precisa de chamar o método OnPropertyChanged em vez disso.

// MvvmLight
PropertyChangedEventHandler handler = PropertyChangedHandler;

// MVVM Toolkit
OnPropertyChanged();

Migração do ViewModelBase

Os passos seguintes centram-se na migração dos seus componentes existentes que tiram partido de ViewModelBase do MvvmLight Toolkit.

O MVVM Toolkit fornece um ObservableRecipient tipo que oferece funcionalidades semelhantes.

Abaixo está uma lista de migrações que terão de ser realizadas caso estejam a ser usadas na sua solução atual.

Métodos da ViewModelBase

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

Set<T>(string, ref T, T, bool) não tem substituição de assinatura de método semelhante.

No entanto, SetProperty<T>(ref T, T, bool, string) fornece a mesma funcionalidade com parâmetros reordenados.

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

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

Note que os parâmetros booleanos de valor e broadcast não são opcionais na implementação do MVVM Toolkit e devem ser fornecidos para usar este método. A razão para esta alteração é que, ao omitir o parâmetro de difusão ao chamar este método, este chamará, por predefinição, o método SetProperty do ObservableObject.

Além disso, o string parâmetro não é necessário se o método estiver a ser chamado a partir do setter da propriedade, pois é inferido a partir do nome do membro do chamador, tal como acontece com os métodos da classe base ObservableObject .

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

Set<T>(ref T, T, bool, string) tem um substituto direto renomeado, 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ão tem um substituto direto.

Recomenda-se que, para melhorar o desempenho, substitua isto pelo SetProperty<T>(ref T, T, bool, string) do MVVM Toolkit, utilizando a palavra-chave nameof em vez disso.

// 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) tem uma substituição direta que não requer renomeação.

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

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

Tenha em atenção que a mensagem enviada através da propriedade Messenger ao chamar o método Broadcast tem um substituto direto em PropertyChangedMessage na biblioteca MVVM Toolkit.

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

Não existe substituto direto para o RaisePropertyChanged<T>(string, T, T, bool) método.

A alternativa mais simples é chamar OnPropertyChanged e depois ligar Broadcast para alcançar esta funcionalidade.

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

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

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

Não existe substituto direto para o RaisePropertyChanged<T>(Expression, T, T, bool) método.

A alternativa mais simples é chamar OnPropertyChanged e depois ligar Broadcast para alcançar esta funcionalidade.

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

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

ICleanup.Cleanup()

Não há substituto direto para a ICleanup interface.

No entanto, o ObservableRecipient fornece um OnDeactivated método que deve ser usado para fornecer a mesma funcionalidade que Cleanup.

OnDeactivated no MVVM Toolkit também irá anular o registo de todos os eventos do Messenger registados quando for chamado.

// MvvmLight
Cleanup();

// MVVM Toolkit
OnDeactivated();

Note que os métodos OnActivated e OnDeactivated podem ser chamados a partir da sua solução existente, tal como com o Cleanup.

No entanto, o ObservableRecipient expõe a propriedade IsActive, que também controla a chamada a estes métodos quando está definida.

Propriedades do ViewModelBase

MessengerInstance

MessengerInstance tem um substituto direto renomeado, Messenger.

// MvvmLight
IMessenger messenger = MessengerInstance;

// MVVM Toolkit
IMessenger messenger = Messenger;

IsInDesignMode

Não existe substituição direta para a propriedade IsInDesignMode e qualquer código que a utilize deve ser alterado ou removido.

A razão para a omissão do MVVM Toolkit é que a IsInDesignMode propriedade expôs implementações específicas de cada plataforma. O MVVM Toolkit foi concebido para ser independente da plataforma.

// MvvmLight
var isInDesignMode = IsInDesignMode;

// MVVM Toolkit
// No direct replacement, remove

Propriedades estáticas do ViewModelBase

IsInDesignModeStatic

Não existe substituição direta para a propriedade IsInDesignModeStatic e qualquer código que a utilize deve ser alterado ou removido.

A razão para a omissão do MVVM Toolkit é que a IsInDesignMode propriedade expôs implementações específicas de cada plataforma. O MVVM Toolkit foi concebido para ser independente da plataforma.

// MvvmLight
var isInDesignMode = ViewModelBase.IsInDesignModeStatic;

// MVVM Toolkit
// No direct replacement, remove

Migração do RelayCommand

Os passos seguintes centram-se na migração dos seus componentes existentes que tiram partido de RelayCommand do MvvmLight Toolkit.

O MVVM Toolkit fornece um RelayCommand tipo que oferece funcionalidades semelhantes, tirando partido da ICommand interface do Sistema.

Abaixo está uma lista de migrações que terão de ser realizadas caso estejam a ser usadas na sua solução atual. Quando um método ou propriedade não está listado, há uma substituição direta com o mesmo nome no MVVM Toolkit e não é necessária qualquer alteração.

A primeira alteração aqui será trocar diretivas usando os seus componentes.

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

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Utilização do RelayCommand com ações assíncronas

Se está atualmente a usar a implementação MvvmLight RelayCommand com ações assíncronas, o MVVM Toolkit expõe uma implementação melhorada para estes cenários.

Pode simplesmente substituir o seu existente RelayCommand pelo AsyncRelayCommand que foi construído para fins assíncronos.

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

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

Métodos de RelayCommand

RaiseCanExecuteChanged()

A funcionalidade de RaiseCanExecuteChanged() pode ser obtida com o método NotifyCanExecuteChanged() do MVVM Toolkit.

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

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

Migração RelayCommand<T>

Os passos seguintes centram-se na migração dos seus componentes existentes que tiram partido de RelayCommand<T> do MvvmLight Toolkit.

O MVVM Toolkit fornece um tipo RelayCommand<T> que oferece funcionalidade equivalente, tirando partido da interface de sistema ICommand.

Abaixo está uma lista de migrações que terão de ser realizadas caso estejam a ser usadas na sua solução atual. Quando um método ou propriedade não está listado, há uma substituição direta com o mesmo nome no MVVM Toolkit e não é necessária qualquer alteração.

A primeira alteração aqui será trocar diretivas usando os seus componentes.

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

// MVVM Toolkit
using CommunityToolkit.Mvvm.Input;

Usando RelayCommand com ações assíncronas

Se está atualmente a usar a implementação MvvmLight RelayCommand<T> com ações assíncronas, o MVVM Toolkit expõe uma implementação melhorada para estes cenários.

Pode simplesmente substituir o seu existente RelayCommand<T> pelo AsyncRelayCommand<T> que foi construído para fins assíncronos.

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

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

RelayCommand<T> Métodos

RaiseCanExecuteChanged()

A funcionalidade de RaiseCanExecuteChanged() pode ser obtida com o método NotifyCanExecuteChanged() do MVVM Toolkit.

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

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

Migração SimpleIoc

A implementação do IoC no MVVM Toolkit não inclui lógica incorporada para gerir a injeção de dependências por si só, por isso podes usar qualquer biblioteca de terceiros para recuperar uma IServiceProvider instância que depois podes passar para o Ioc.ConfigureServices método. Nos exemplos abaixo, será utilizado o tipo ServiceCollection da biblioteca Microsoft.Extensions.DependencyInjection.

Esta é a maior mudança entre o MvvmLight e o MVVM Toolkit.

Esta implementação parecerá familiar se já implementou injeção de dependências com aplicações ASP.NET Core.

Registar as suas dependências

Com o MvvmLight, pode ter registado as suas dependências de forma semelhante a estes cenários usando SimpleIoc.

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

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

Com o MVVM Toolkit, conseguiria o mesmo que segue.

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

Resolução de dependências

Uma vez inicializados, os serviços podem ser recuperados da Ioc classe tal como acontece com SimpleIoc:

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

Ao migrar para o MVVM Toolkit, conseguirá o mesmo com:

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

Remoção de dependências

Com SimpleIoc, anularia o registo das suas dependências através da seguinte chamada de método.

SimpleIoc.Default.Unregister<INavigationService>();

Não existe substituto direto para a remoção de dependências com a implementação do MVVM Toolkit Ioc .

Construtor preferencial

Ao registar as suas dependências com o SimpleIoc do MvvmLight, tem a possibilidade de, nas suas classes, fornecer um atributo PreferredConstructor para as que tenham vários construtores.

Este atributo terá de ser removido onde for usado, e terá de usar quaisquer atributos da biblioteca de injeção de dependências de terceiros em uso, se for suportado.

Migração Messenger

Os passos seguintes centram-se na migração dos componentes existentes que tiram partido de Messenger do MvvmLight Toolkit.

O MVVM Toolkit fornece duas implementações de mensageiro (WeakReferenceMessenger e StrongReferenceMessenger, ver documentação aqui) que oferecem funcionalidades semelhantes, com algumas diferenças chave detalhadas abaixo.

Abaixo está uma lista de migrações que terão de ser realizadas caso estejam a ser usadas na sua solução atual.

A primeira alteração aqui será trocar diretivas usando os seus componentes.

// MvvmLight
using GalaSoft.MvvmLight.Messaging;

// MVVM Toolkit
using CommunityToolkit.Mvvm.Messaging;

Métodos do Messenger

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

A funcionalidade de Register<TMessage>(object, Action<TMessage>) pode ser obtida com o método de extensão IMessenger do MVVM Toolkit 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));

A razão desta assinatura é que permite ao mensageiro usar referências fracas para rastrear corretamente os destinatários e evitar criar fechos para capturar o próprio destinatário. Ou seja, o destinatário da entrada é passado como entrada para a expressão lambda, pelo que não precisa de ser capturado pela própria expressão lambda. Isto também resulta em código mais eficiente, pois o mesmo handler pode ser reutilizado várias vezes sem alocações. Note que esta é apenas uma das formas suportadas de registar manipuladores e que também é possível utilizar, em vez desta, a interface IRecipient<TMessage> (conforme detalhado na documentação do Messenger), o que torna o registo automático e menos verboso.

Além disso, este exemplo e os abaixo vão apenas usar a Messenger propriedade de ObservableRecipient. Se quiseres aceder estaticamente a uma instância do messenger a partir de qualquer outra parte do teu código, os mesmos exemplos também se aplicam, com a única diferença de que Messenger precisa de ser substituído por, por exemplo, WeakReferenceMessenger.Default em vez disso.

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

Não existe substituto direto para este mecanismo de registo, que permite suportar a receção de mensagens para tipos de mensagens derivados. Esta alteração é intencional, pois a Messenger implementação pretende não usar reflexão para alcançar os seus benefícios de desempenho.

Alternativamente, existem algumas opções que podem ser feitas para alcançar esta funcionalidade.

• Crie uma implementação personalizada IMessenger .
• Regista os tipos de mensagens adicionais usando um handler partilhado, depois verifica o tipo e invoca o método correto.

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

A funcionalidade de Register<TMessage>(object, object, Action<TMessage>) pode ser obtida com o método Register<TRecipient, TMessage, TToken>(object, TToken, MessageHandler<TRecipient, TMessage>) do MVVM Toolkit.

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

Não existe substituto direto para este mecanismo de registo, que permite suportar a receção de mensagens para tipos de mensagens derivados. Esta alteração é intencional, pois a Messenger implementação pretende não usar reflexão para alcançar os seus benefícios de desempenho.

Alternativamente, existem algumas opções que podem ser feitas para alcançar esta funcionalidade.

• Crie uma implementação personalizada IMessenger .
• Regista os tipos de mensagens adicionais usando um handler partilhado, depois verifica o tipo e invoca o método correto.

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

A funcionalidade de Send<TMessage>(TMessage) pode ser obtida com o método de extensão IMessengerSend<TMessage>(TMessage) do MVVM Toolkit.

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

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

No cenário acima, onde a mensagem enviada tem um construtor sem parâmetros, o MVVM Toolkit tem uma extensão simplificada para enviar uma mensagem neste formato.

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

Send<TMessage>(TMessage, object)

A funcionalidade de Send<TMessage>(TMessage, object) pode ser obtida com o método Send<TMessage, TToken>(TMessage, TToken) do MVVM Toolkit.

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

A funcionalidade de Unregister(object) pode ser obtida com o método UnregisterAll(object) do MVVM Toolkit.

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

// MVVM Toolkit
Messenger.UnregisterAll(this);

Unregister<TMessage>(object)

A funcionalidade de Unregister<TMessage>(object) pode ser obtida com o método de extensão IMessengerUnregister<TMessage>(object) do MVVM Toolkit.

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

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

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

Não existe substituto direto para o Unregister<TMessage>(object, Action<TMessage>) método no MVVM Toolkit.

A razão para esta omissão é que o destinatário da mensagem só pode ter um único gestor registado para cada tipo de mensagem.

Recomendamos obter esta funcionalidade com o método de extensão IMessengerUnregister<TMessage>(object) do MVVM Toolkit.

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

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

Unregister<TMessage>(object, object)

A funcionalidade de Unregister<TMessage>(object, object) pode ser alcançada com o método Unregister<TMessage, TToken>(object, TToken) do toolkit MVVM.

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

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

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

Não existe substituto direto para o Unregister<TMessage>(object, object, Action<TMessage>) método no MVVM Toolkit.

A razão para esta omissão é que o destinatário da mensagem só pode ter um único gestor registado para cada tipo de mensagem.

Recomendamos obter esta funcionalidade com o método Unregister<TMessage, TToken>(object, TToken) do MVVM Toolkit.

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

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

Cleanup()

O Cleanup método tem uma substituição direta com o mesmo nome no MVVM Toolkit. Tenha em atenção que este método só é útil quando está a ser utilizado um mensageiro que usa referências fracas, enquanto o tipo StrongReferenceMessenger simplesmente não fará nada quando este método for chamado, uma vez que o estado interno já é limpo automaticamente à medida que o mensageiro é utilizado.

// MvvmLight
Messenger.Default.Cleanup();

// MVVM Toolkit
Messenger.Cleanup();

RequestCleanup()

Não existe substituto direto para o RequestCleanup método no MVVM Toolkit. No contexto do MvvmLight, RequestCleanup é usado para iniciar um pedido de remoção de registos que já não estão ativos, pois a implementação aproveita referências fracas.

Quaisquer chamadas ao RequestCleanup método podem ser removidas ou substituídas por Cleanup.

// MvvmLight
Messenger.Default.RequestCleanup();

// MVVM Toolkit
// No direct replacement, remove

ResetAll()

A funcionalidade de ResetAll() pode ser alcançada com o método Reset() do toolkit MVVM.

Ao contrário da implementação do MvvmLight, que anula a instância, o MVVM Toolkit apaga os mapas registados.

// MvvmLight
Messenger.Default.ResetAll();

// MVVM Toolkit
Messenger.Reset();

Métodos estáticos do Messenger

OverrideDefault(IMessenger)

Não existe substituto direto para o OverrideDefault(IMessenger) método no MVVM Toolkit.

Para usar uma implementação personalizada do IMessenger, regista-se a implementação personalizada nos registos de serviço para injeção de dependências ou constrói manualmente uma instância estática e passa-a onde necessário.

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

// MVVM Toolkit
// No direct replacement

Reset()

Não existe substituto direto para o método estático Reset no MVVM Toolkit.

A mesma funcionalidade pode ser alcançada ao chamar o Reset método da instância estática Default de um dos tipos de mensageiro.

// MvvmLight
Messenger.Reset();

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

Propriedades estáticas do mensageiro

Default

Default tem uma substituição direta, Default, que não requer alterações à sua implementação atual.

// MvvmLight
IMessenger messenger = Messenger.Default;

// MVVM Toolkit
IMessenger messenger = WeakReferenceMessenger.Default;

Tipos de mensagens migratórias

Os tipos de mensagens fornecidos na biblioteca MvvmLight foram concebidos como uma base com a qual pode trabalhar, enquanto programador, se necessário.

Embora o MVVM Toolkit ofereça algumas alternativas, não existem substitutos diretos para estes tipos de mensagens. Recomendamos que vejamos os tipos de mensagens disponíveis.

Alternativamente, se a sua solução tirar partido dos tipos de mensagem MvvmLight, estes podem ser facilmente portados para a sua própria base de código.

Migração de componentes específicos da plataforma

Na implementação atual do MVVM Toolkit, não existem substitutos para componentes específicos da plataforma que existem no kit de ferramentas MvvmLight.

Os seguintes componentes e os seus ajudantes/métodos de extensão associados não têm substituto e terão de ser considerados ao migrar para o MVVM Toolkit.

Específico para Android/iOS/Windows

• DialogService
• DispatcherHelper
• NavigationService

Específico para Android/iOS

• ActivityBase
• Binding
• BindingMode
• PropertyChangedEventManager
• UpdateTriggerMode

Especificamente para Android

• CachingViewHolder
• ObservableAdapter
• ObservableRecyclerAdapter

Específico para iOS

• ObservableCollectionViewSource
• ObservableTableViewController
• ObservableTableViewSource

Ajudantes

• Empty
• WeakAction
• WeakFunc