1.MVVM简介

1.1MVVM简介

MVVM是Model、View、ViewModel的简写，这种模式的引入就是使用ViewModel来降低View（界面）和Model（逻辑）的耦合。

Model就是一个类， View就是界面，ViewModel就是对View的抽象。显示的数据对应着ViewMode中的Property（属性），执行的命令对应着ViewModel中的Command（命令）。

1.2WPF中MVVM的解耦方式

在WPF的MVVM模式中，View和ViewModel之间数据和命令的关联都是通过绑定实现的，绑定后View和ViewModel并不产生直接的依赖。具体就是View中出现数据变化时会尝试修改绑定的目标。同样View执行命令时也会去寻找绑定的Command并执行。反过来，ViewModel在Property发生改变时会发个通知说“名字叫XXX的Property改变了，你们这些View中谁绑定了XXX也要跟着变啊!”，至于有没有View收到是不是做出变化也不关心。ViewModel中的Command脱离View就更简单了，因为Command在执行操作过程中操作数据时，根本不需要操作View中的数据，只需要操作ViewModel中的Property就可以了，Property的变化通过绑定就可以反映到View上。这样在测试Command时也不需要View的参与。这也是我在接触WPF初期时根本理解不了的所谓数据驱动。

这样一来ViewMode可以在完全没有View的情况下测试，View也可以在完全没有ViewModel的情况下测试(当然只是测试界面布局和动画等业务无关的内容)。

1.3MVVM框架需要解决的问题

从图中可以看出如果要实现一套MVVM框架，需要解决的最基本的问题就是数据绑定和命令绑定。此外由于UI中会产生大量的事件，因此还需要将事件绑定到MVVM中的命令上。后面将依次尝试解决这些问题。

2.数据绑定要达到的效果

2.1. 数据绑定要达到的效果

从界面反映到绑定的数据源是很容易理解的，因为在绑定过程中我们指定了DataContext和Binding的对象，很容易找到绑定的源并修改。但数据源修改时怎么通知界面呢？因为ViewModel中被绑定的属性并不知道谁绑定了它，如果在ViewModel中存一个View的引用，在数据发生变化时修改View，这无疑又将ViewModel和View耦合在了一起，而且这样做View中相应的控件没有开发完善难以进行测试，同样View中控件类型或名称发生改变时，ViewModel中相关代码都需要修改。在WPF中从数据源通知界面发生变化是通过发送通知的方式进行的，你可以想象一个string类型的Property，名字是TestString，在它发生变化时对着View大喊“TestString发生变化了，你们谁绑定了TestString需要跟着变啊！”，至于绑定的是TextBlock的Text，还是Label的Content，还是TextBox的Text，ViewModel并不关心，同样喊了后结果如何ViewModel也不关心。View在收到这个通知后看有没有绑定了TestString的地方，找到了就修改，找不到就不管了，也不会在乎这个通知是哪个类型的ViewModel发的。这样ViewModel和View就解耦了，谁也不依赖对方。

2.2. INotifyPropertyChanged接口

在WPF中能够实现ViewModel向View喊话功能的就是INotifyPropertyChanged接口，它就像一个大喇叭一样，我们实现了这个接口，就可以通过触发PropertyChanged事件并给出改变的数据源的对象和属性名称，以此来通知数据的变化。这个接口的实现是非常简单的，下图代码就是一种非常简易的实现方式。由于在MVVM中所有的ViewModel和部分Model都需要实现这个接口来达到绑定的效果，因此一般会专门用一个类来实现这个接口，并将这个类作为ViewModel等需要数据更改后发送通知的类的基类。

using System.ComponentModel;

namespace mvvwkuangjia
{
    /// <summary>
    /// 相当于一个大喇叭，实现通知View层进行修改相应的控件属性
    /// </summary>
    class NotificationBase : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;


        public void RaisePropertyChanged(string propertyName) =>PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

3.命令绑定

3.1命令绑定要达到的效果

命令绑定要关注的核心就是两个方面的问题，命令能否执行和命令怎么执行。也就是说当View中的一个Button绑定了ViewModel中一个命令后，什么时候这个Button是可用的，按下Button后执行什么操作。解决了这两个问题基本就实现了命令绑定。另外一个问题就是执行过程中需要的数据（参数）要如何传递。

3.2命令绑定的实现

自定义一个能够被绑定的命令需要实现ICommand接口。该接口包含:

public event EventHandler CanExecuteChanged // 在命令可执行状态发生改变时触发
public bool CanExecute(object parameter) //检查命令是否可用的方法
public void Execute(object parameter)  //命令执行的方法

那么要如何实现这个接口呢?那得先搞明白这个接口是干什么用的。MSDN上是这么说的：

https://msdn.microsoft.com/zh-cn/library/system.windows.input.icommand(v=vs.110).aspx

CanExecute和Execute方法是接口给出的，我们要做的就是新建一个类MyCommand来实现这两个方法执行的内容。可以通过在MyCommand的构造函数中传入Action<object>和Func<object,bool>，让CanExecute执行Func<object,bool>，Execute执行Action<object>。命令绑定时经常需要传参数，这种情况下可以给MyCommand添加泛型支持，实现后MyCommand结构如下所示。

using System;
using System.Windows.Input;

namespace mvvwkuangjia
{
    class MyCommand : ICommand
    {
        public Action<object> executeCommand = null;
        public Func<object, bool> canExecuteCommand = null;
        public event EventHandler CanExecuteChanged;

        public MyCommand(Action<object> executeCommand, Func<object, bool> canExecuteCommand)
        {
            this.executeCommand = executeCommand;
            this.canExecuteCommand = canExecuteCommand;
        }

        public bool CanExecute(object parameter)
        {
            if (canExecuteCommand == null) return true;
            else return canExecuteCommand(parameter);
        }

        public void Execute(object parameter)
        {
            if (executeCommand != null && CanExecute(parameter))
                executeCommand(parameter);
        }

        public void RaiseCanExecuteChanged() => CanExecuteChanged?.Invoke(this, EventArgs.Empty);
    }
}

4.事件绑定

4.1为什么要事件绑定

这个问题其实是很好理解的，因为事件是丰富多样的，单纯的命令绑定远不能覆盖所有的事件。例如Button的命令绑定能够解决Click事件的需求，但Button的MouseEnter、窗体的Loaded等大量的事件要怎么处理呢？这就用到了事件绑定。

4.2 事件绑定

要使用事件绑定需要借助System.Windows. interactivity，如果安装了Blend，里面就包含了这个dll。如果缺少，你需要安装Blend SDK，这是链接：https://www.microsoft.com/en-us/download/details.aspx?id=10801 安装到默认目录下再添加引用即可。需要在Interaction.Triggers里面添加一个或多个EventTrigger并指定关注的的事件名称，在EventTrigger中通过InvokeCommandAction来绑定事件对应的命令。图中所示绑定了主窗口的Loaded事件，在事件触发后会调用绑定的命令对象LoadedCommand的Execute方法执行命令，当命令绑定需要参数时可以通过绑定CommandParameter实现。需要指出的是之前在实现MyCommand的Execute方法时我们加入了CanExecute的判断，因此事件触发后是否能够真正执行绑定的命令也受到绑定的LoadedCommand的CanExecute方法的影响。

4.3带EventArgs参数的事件绑定

上面介绍的事件绑定并不足以应对所有的情况，因为很多情况下我们还需要从事件的EventArgs中获取数据，例如从MouseMove事件参数中获取鼠标位置和按键状态等。但InvokeCommandAction在未对CommandParameter绑定的情况下给Execute方法传递的参数为null。因此我们需要自己写一个类来处理事件到命令的绑定。

看一下上面我们用到的InvokeCommandAction，继承自TriggerAction<DependencyObject>，TriggerAction是一个抽象类，我们只要继承这个类并实现Invoke方法即可。TriggerAction在MSDN中的介绍如下：

https://msdn.microsoft.com/zh-cn/library/system.windows.interactivity.triggeraction(v=expression.40).aspx

我简单实现了以下，代码如下图所示，不绑定CommandParameter则传递的就是事件的参数。如果绑定了CommandParameter，那么传递的就是绑定的参数。有时候Xaml文件找不到类，需要先生成一下，再在Xaml文件中使用。

<Window x:Class="mvvw框架示例.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
        xmlns:local="clr-namespace:mvvw框架示例"
        mc:Ignorable="d"
        Title="MainWindow" Height="350" Width="525">

    <i:Interaction.Triggers>
        <i:EventTrigger EventName="Loaded">
            <i:InvokeCommandAction Command="{Binding LoadedCommand}"/>
        </i:EventTrigger>
        <i:EventTrigger EventName="MouseMove">
            <local:MyEventCommand Command="{Binding MouseMoveCommand}"/>
        </i:EventTrigger>
    </i:Interaction.Triggers>
<Window>

5.View和ViewModel的通信

消息通信的方式主要受到MVVMLight的启发，MVVMLight实现了一套略有复杂的消息通信，包含了定类型发送、分组发送、发送给包含继承类型的目标、广播等。就目前我做的几个小项目来说，View和ViewModel通信本身用的就不是那么频繁，需求也不算旺盛，所以自己实现了一套比较简易的消息通信。View在实例化的时候注册消息，通过一个列表保存注册的消息，消息在发送的时候根据条件从列表中找到相应的消息并执行操作，如下图所示：

消息发送和处理：

比较奇怪的是为什么要引入一个消息注册器，在View的后台代码中直接注册不就可以了吗?好吧，其实最初只是单纯的不想在后台中写入太多的代码，这样看上去似乎更高端。不过后来想了下，View对ViewModel(虽然不是接口)和消息注册器实际上都算是一种依赖，而且View对ViewModel和消息注册器的依赖都是唯一的，也就是说一个View只有一个ViewModel和一个消息注册器。这样可以用控制反转的方式把对ViewModel和消息注册器的依赖一起注入进来，而且在注入过程中可以顺便配置ViewModel的Dispatcher以方便跨线程修改UI，也可以给ViewModel配置单独的MessageManager让View和ViewModel的通信进入另一个次元，不受其他消息干扰。这些在讨论ViewModel依赖注入的时候将会尝试。

关于跨线程修改UI

这个顺带提一下，因为实现起来很简单。在ViewModel中有时会遇到使用其它线程修改UI的情况，我之前是通过 App.Current.MainWindow.Dispatcher来获取UI线程的调度器的。当然也可以把UI线程的调度器保存到一个静态变量中以便随时访问。不过我一直没搞明白MaiWindow的Dispatcher和非MainWindow的Dispatcher有什么区别，不过还是在ViewModel的基类中加入了Dispatcher这个属性，这样在给View注入ViewModel的时候可以把ViewModel的Dispatcher设置为绑定的View的Dispatcher，虽然并不太清楚这有什么卵用

MVVM理解笔记