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中的介绍如下:
我简单实现了以下,代码如下图所示,不绑定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,虽然并不太清楚这有什么卵用