使用 MVVM Light Messanger 代替事件

Using MVVM Light Messanger instead of Events

我正在为我当前的 WPF 项目使用 MVVM Light,我想知道什么时候应该使用 MVVM Light 的 WPF 事件消息传递。

WPF 事件:

MyControl.xaml

<ListView SelectionChanged="ListView_OnSelectionChanged" />

MyControl.cs

private MyViewModel ViewModel
{
    get { return this.DataContext as MyViewModel; }
}

private void ListView_OnSelectionChanged( object sender, SelectionChangedEventArgs e )
{
    this.ViewModel.ListViewSelectionChanged( ( (ListView) sender ).SelectedItems );
}

MVVM 轻型消息传递:

MyControl.cs

private void ListView_OnSelectionChanged( object sender, SelectionChangedEventArgs e )
{
    Messenger.Default.Send( new ListViewSelectionMessage {SelectedItems = ((ListView)sender).SelectedItems} );
}

ListViewSelectionMessage.cs

public class ListViewSelectionMessage
{
    public IList SelectedItems { get; set; }
}

MyViewModel

public class MyViewModel
{
    MyViewModel()
    {
        Messenger.Default.Register<ListViewSelectionMessage>(this, this.ListViewSelectionChaged);
    }

    private void ListViewSelectionChaged( ListViewSelectionMessage message )
    {
        // ...
    }
}

因为使用 Messanger,一切都很容易解耦,所以我很想在任何地方都使用 Messanger。使用 Messanger 而不是 Events 有什么问题吗?或者这会产生我不知道的问题。谢谢!

通常,任何 MVVM 框架(Prism、MVVM Light)中的消息都是在具有插件架构的应用程序中松散耦合的组件之间进行通信的好方法,因为您可以通过共享库中声明的合同将消息从一个模块发送到另一个模块。在您单独开发应用程序或在小团队高技能程序员中使用它是可以的。

否则有一个很大的缺点:重构和调试非常困难,因为你不能只点击消息并且"find usages"你需要先去合同(接口)而不是"find usages",然后用 Subscribe/Register 指令直观地找到地方。此外,开发人员通常会忘记取消订阅消息,因此当从一个模块发送并打算在同一模块中处理的消息将被错误地在其他模块中处理时,您将面临问题,因此会导致意外行为并产生许多痛苦的错误。

以上所有内容均基于我的个人经验,因此结果可能会有所不同。请小心处理消息,它会很好地为您服务。同样在我看来,消息作为事件的替代品有点 overhead/overengineering 因为当你有紧密耦合的组件时你并不真正需要它。