了解 WPF 中的路由事件和命令
http://msdn.microsoft.com/zh-cn/magazine/cc785480.aspx
Brian Noyes
代码下载位置： RoutedWPF2008_09a.exe (175 KB)
在线浏览代码
|
本文将介绍以下内容：
|
本文使用了以下技术： |
目录
路由事件概述
WPF 元素树
事件路由
路由事件和组合
附加事件
路由命令概述
操作中的路由命令
命令路由
定义命令
命令插入
路由命令的局限
避免命令出错
超越路由命令
路由处理程序示例
要想尽快熟悉 Windows® Presentation Foundation (WPF)，必须要面对的一个难题是有许多需要掌握的新结构。甚至 Microsoft® .NETFramework 属性和事件这类简单的事物，在 WPF 中也有新的对应项，功能有所更新且更为复杂——尤其是依赖关系属性和路由事件，这一特点更为显著。还有就是那些全新的内容，如动画、样式设定、控制模板和路由命令等。要学习的东西太多了。
在本文中，我将重点介绍两个极为重要的 WPF 新元素项。这两个元素项就是相互关联的路由事件和路由命令。它们是用户界面上不同部件进行通信的基础——这些部件可以是一个大的 Window 类的单个控件，也可以是用户界面上单独分离部件的控件及其支持代码。在本文中，我假定您已经对 WPF 有了一定的了解，比如说，知晓如何使用内置 WPF 控件并通过以 XAML 声明 UI 布局来构建 UI。
路由事件概述
刚开始接触 WPF 时，您可能会在自己并不知晓的情况下就用到了路由事件。例如，当您在 Visual Studio® 设计器中向窗口添加一个按钮，并将其命名为 myButton，然后双击该按钮时，Click 事件将挂接在您的 XAML 标记之内，它的事件处理程序会添加到 Window 类的代码隐藏中。这种感觉与在 Windows 窗体和 ASP.NET 中挂接事件并无二致。实际上，它比较接近 ASP.NET 的代码编写模型，但更类似 Windows 窗体的运行时模型。具体来说，在按钮的 XAML 标记中，代码的结尾类似如下所示：
<ButtonName="myButton" Click="myButton_Click">ClickMe</Button>
挂接事件的 XAML 声明就象 XAML 中的属性分配，但结果是针对指定事件处理程序的对象产生一个正常的事件挂接。此挂接实际上出现在编译时生成的窗口局部类中。要查看这一挂接，转到类的构造函数，右键单击 InitializeComponent方法调用，然后从上下文菜单中选择“转到定义”。编辑器将显示生成的代码文件（其命名约定为 .i.g.cs 或 .i.g.vb），其中包括在编译时正常生成的代码。在显示的局部类中向下滚动到 Connect 方法，您会看到下面的内容：
#line 6"..\..\Window1.xaml"
this.myButton.Click +=
new System.Windows.RoutedEventHandler(
this.myButton_Click);
这一局部类是在编译时从 XAML 中生成的，其中包含那些需要设计时编译的 XAML 元素。大部分 XAML 最终都会成为编译后程序集中嵌入了二进制的资源，在运行时会与二进制标记表示的已编译代码合并。
如果看一下窗口的代码隐藏，您会发现 Click 处理程序如下所示：
private voidmyButton_Click(
object sender, RoutedEventArgs e) { }
到目前为止，它看起来就象任何其他 .NET 事件挂接一样——您有一个显式声明的委托，它挂接到一个对象事件且委托指向某个处理方法。使用路由事件的唯一标记是 Click 事件的事件参数类型，即 RoutedEventArgs。那么路由事件究竟有何独特之处呢？要理解这一点，首先需要了解 WPF 元素化的组合模型。
WPF 元素树
如果您在项目中开启一个新窗口并在设计器中将按钮拖入窗口内，您会得到 XAML 格式的元素树，如下所示（为了清楚略去了属性）：
<Window>
<Grid>
<Button/>
</Grid>
</Window>
其中的每个元素都代表对应 .NET 类型的一个运行时实例，元素的声明分层结构形成了所谓的逻辑树。此外，WPF 中的许多控件不是 ContentControl 就是 ItemsControl，这代表他们可以有子元素。例如，Button 是一个 ContentControl，它可以将复杂的子元素做为其内容。您可以展开逻辑树，如下所示：
<Window>
<Grid>
<Button>
<StackPanel>
<Image/>
<TextBlock/>
</StackPanel>
</Button>
</Grid>
</Window>
生成的 UI 如图 1 所示。
图 1 包含按钮内容的简单窗口
如您所想，树可以有多个分支（Grid 中的另一 Button），因此逻辑树会变得极为复杂。对于逻辑树的 WPF 元素，您需要意识到您所见到的并不是您在运行时真正得到的内容。每个这样的元素通常都会在运行时扩展为更为复杂的可视元素树。在本例中，元素的逻辑树扩展为可视元素树，如图 2 所示。
图 2简单窗口可视树
我使用名为 Snoop 的工具 (blois.us/Snoop) 查看图 2 中所示可视树的元素。您可以看到窗口 (EventsWindow) 实际是将其内容置入 Border 和AdornerDecorator 之内，用ContentPresenter 显示其中的内容。按钮也与此类似，将其内容置入 ButtonChrome 对象，然后用 ContentPresenter 显示内容。
单击按钮时，我可能实际根本没有单击 Button 元素，可能是单击可视树中的某一子元素，甚至是逻辑树中未显示的元素（如 ButtonChrome）。例如，假设我在按钮内的图像上方单击鼠标。这一单击操作在一开始实际是将其表达为 Image 元素中的 MouseLeftButtonDown 事件。但却需要转化为 Button 层级的 Click 事件。这就要引入路由事件中的路由。
事件路由
对逻辑树和可视树有所了解很有必要，因为路由事件主要是根据可视树进行路由。路由事件支持三种路由策略：气泡、隧道和直接。
气泡事件最为常见，它表示事件从源元素扩散（传播）到可视树，直到它被处理或到达根元素。这样您就可以针对源元素的上方层级对象处理事件。例如，您可向嵌入的 Grid 元素附加一个 Button.Click 处理程序，而不是直接将其附加到按钮本身。气泡事件有指示其操作的名称（例如，MouseDown）。
隧道事件采用另一种方式，从根元素开始，向下遍历元素树，直到被处理或到达事件的源元素。这样上游元素就可以在事件到达源元素之前先行截取并进行处理。根据命名惯例，隧道事件带有前缀 Preview（例如 PreviewMouseDown）。
直接事件类似 .NET Framework 中的正常事件。该事件唯一可能的处理程序是与其挂接的委托。
通常，如果为特殊事件定义了隧道事件，就会有相应的气泡事件。在这种情况下，隧道事件先触发，从根元素开始，下行至源元素，查找处理程序。一旦它被处理或到达源元素，即会触发气泡事件，从源元素上行，查找处理程序。气泡或隧道事件不会仅因调用事件处理程序而停止路由。如果您想中止隧道或气泡进程，可使用您传递的事件参数在事件处理程序中将事件标记为已处理。
private void OnChildElementMouseDown(objectsender,
MouseButtonEventArgs e) {
e.Handled = true;
}
一旦您的处理程序将事件标记为已处理，该事件便不会传给任何其他处理程序。这一论断只是部分正确。实际上，事件路由仍在继续起作用，您可利用UIElement.AddHandler 的替换方法在代码中显式挂接事件处理程序，该方法有一个额外的标记，可以有效指出“即使事件被标记为已处理也可调用我”。您用类似如下所示的调用指定该标记：
m_SomeChildElement.AddHandler(UIElement.MouseDownEvent,
(RoutedEventHandler)OnMouseDownCallMeAlways,true);
AddHandler 的第一个参数是您想要处理的 RoutedEvent。第二个参数是对事件处理方法（它需要有事件委托的正确签名）的委托。第三个参数指明如果另一个处理程序已将事件标记为已处理，您是否想得到通知。您调用 AddHandler 的元素就是在路由期间观察事件流动的元素。
路由事件和组合
现在我们来看一看 Button.Click 事件的形成过程，以了解为什么它如此重要。如前所述，用户将对 Button 可视树中的某些子元素（例如上一示例中的 Image）使用 MouseLeftButtonDown 事件启动 Click 事件。
在 Image 元素内发生 MouseLeftButtonDown 事件时，PreviewMouseLeftButtonDown 在根元素启动，然后沿隧道下行至 Image。如果没有处理程序为 Preview 事件将 Handled 标记设置为 True，MouseLeftButtonDown 即会从 Image 元素开始向上传播，直至到达 Button。按钮处理这一事件，将 Handled 标记设为 True，然后引发其自身的 Click 事件。本文中的示例代码包括一个应用程序，它带有整个路由链挂接的处理程序，可帮您查看这一进程。
其蕴含的意义不可小视。例如，如果我选择通过应用包含 Ellipse 元素的控件模板替换默认按钮外观，可以保证在 Ellipse 外部单击即可触发 Click 事件。靠近 Ellipse 的外缘单击仍处于 my button 的矩形边界内，但 Ellipse 有其自身的 MouseLeftButtonDown 击中检测，而 Ellipse 外部按钮的空白区域则没有。
因此，只有在 Ellipse 内部的单击才会引发 MouseLeftButtonDown 事件。它仍由附加此模板的 Button 类进行处理，所以，即便是自定义的按钮，您也能得到预测的行为。在编写自己自定义的复合控件时也需牢记这一非常重要的概念，因为您的操作很可能类似 Button 对控件内子元素的事件处理。
附加事件
为了让元素能处理在不同元素中声明的事件，WPF 支持附加事件。附加事件也是路由事件，它支持元素 XAML 形式的挂接，而非声明事件所用的类型。例如，如果您想要 Grid 侦听采用气泡方式通过的 Button.Click 事件，仅需按如下所示进行挂接即可。
<GridButton.Click="myButton_Click">
<Button>Click Me</Button>
</Grid>
在编译时生成的局部类中的最终代码现在如下所示：
#line 5"..\..\Window1.xaml"
((System.Windows.Controls.Grid)(target)).AddHandler(
System.Windows.Controls.Primitives.ButtonBase.ClickEvent,
newSystem.Windows.RoutedEventHandler(this.myButton_Click));
附加事件可在挂接事件处理程序位置方面给予您更大的灵活性。但如果元素包含在同一类中（如本例所示），其差异并不会显露出来，这是由于处理方法针对的仍是 Window 类。
它在两方面产生影响。第一，事件处理程序根据处理元素在气泡或隧道元素链中的位置进行调用。第二，您可额外执行一些操作，如从所用控件内封装的对象处理事件。例如，您可以象处理 Grid 中所示的事件一样处理 Button.Click 事件，但这些 Button.Click 事件可以从窗口中包含的用户控件内部向外传播。
提示：事件处理程序命名
如果您不想一味使用事件处理程序的默认命名约定（objectName_eventName），仅需输入您需要的事件处理程序名称，右键单击，然后单击上下文菜单中的“浏览到事件处理程序”即可。Visual Studio 随即按指定的名称生成事件处理程序。
在 Visual Studio2008 SP1 中，“属性”窗口会有一个事件视图，它与 Windows 窗体中的视图类似，因此如果您有 SP1，即可以在那里指定事件名称。但如果您采用的是 XAML，这是生成显式命名的处理程序的便捷方法。
生成事件处理程序（单击图像可查看大图）
并非所有事件都声明为附加事件。实际上，大部分事件都不是这样。但当您需要在控件来源之外处理事件时，附加事件会提供相当大的帮助。
路由命令概述
您已看到了路由事件，接下来我来介绍路由命令。WPF 的路由命令为您提供了一种特定的机制，用于将工具栏按钮和菜单项这类 UI 控件挂接到处理程序，并且无需在应用程序中加入许多关联性很强的重复代码。与正常事件处理相比，路由命令有三大优点：
- 路由命令源元素（调用程序）能够与命令目标（处理程序）分离——它们不需要彼此引用，如果是通过事件处理程序链接，就需要相互引用。
- 处理程序指出命令被禁用时，路由命令将自动启用或禁用所有相关的 UI 控件。
- 您可以使用路由命令将键盘快捷方式与其他形式的输入手势（例如，手写）相关联，作为调用命令的另一种方式。
此外，路由命令特有的 RoutedUICommand类可以定义单一 Text 属性，用做任何控件（命令调用程序）的命令提示。与访问每个相关的调用程序控件相比，Text 属性的本地化更为容易。
要在调用程序上声明命令，仅需在触发命令的控件上设置 Command 属性即可。
<ButtonCommand="ApplicationCommands.Save">Save</Button>
MenuItem、Button、RadioButton、CheckBox、Hyperlink 和许多其他控件都支持 Command 属性。
对于您想用做命令处理程序的元素，可设置 CommandBinding：
<UserControl ...>
<UserControl.CommandBindings>
<CommandBindingCommand="ApplicationCommands.Save"
CanExecute="OnCanExecute"Executed="OnExecute"/>
</UserControl.CommandBindings>
...
</UserControl>
CommandBinding 的 CanExecute 和 Executed 属性指向声明类代码隐藏中的方法，这些方法会在命令处理进程中被调用。此处的要点是命令调用程序既不需要了解，也不需要引用命令处理程序，处理程序不必知道是哪个元素将要调用命令。
调用 CanExecute 来确定是否应启用命令。要启用命令，应将事件参数的 CanExecute 属性设置为 True，如下所示：
private voidOnCanExecute(object sender,
CanExecuteRoutedEventArgs e) {
e.CanExecute = true;
}
如果命令处理程序带有定义的 Executed 方法，但没有 CanExecute 方法，命令也会被启用（在这种情况下，CanExecute 隐式为 true）。通过 Executed 方法，根据调用的命令执行相应的操作。这类与命令相关的操作可以是保存文档、提交订单、发送电子邮件等。
操作中的路由命令
为了使这一概念更为具体并让路由命令的益处立竿见影，我们来看一个简单的示例。在图 3 中，您可看到一个简单的 UI，它有两个输入文本框，一个对文本框中的文本执行 Cut 操作的工具栏按钮。
图 3 包含 Cut 命令工具栏按钮的简单示例
要使用事件完成挂接，需要为工具栏按钮定义 Click 处理程序，且该代码需要引用两个文本框。您需要根据控件中的文本选择确定哪个文本框是焦点项并调用相应的剪贴板操作。还要根据焦点项的位置和文本框中是否有选项，在适当的时候启用或禁用工具栏按钮。代码十分凌乱且复杂。
对于这一简单示例，问题还不大，但如果这些文本框深入用户控件或自定义控件的内部，且窗口代码隐藏无法直接访问它们，情况又会如何？您不得不在用户控件的边界显示 API 以便能从容器实现挂接，或公开显露文本框，两者皆不是理想的方法。
如使用命令，只需将工具栏按钮的 Command 属性设为在 WPF 中定义的 Cut 命令即可。
<ToolBarDockPanel.Dock="Top" Height="25">
<ButtonCommand="ApplicationCommands.Cut">
<Image Source="cut.png"/>
</Button>
</ToolBar>
现在您运行应用程序，会看到工具栏按钮一开始是被禁用的。在其中一个文本框中选择了文本后，工具栏按钮会启用，如果单击该按钮，文本会被剪切到剪贴板。这一操作适用于 UI 中任何位置的任何文本框。喔，很不错吧？
实际上，TextBox 类实现有一个针对 Cut 命令的内置命令绑定，并为您封装了该命令（Copy 和 Paste）的剪贴板处理。那么，命令如何只调用所关注的文本框，消息如何到达文本框并告诉它处理命令？这便是路由命令中路由部件发挥作用的地方。
命令路由
路由命令与路由事件的区别在于命令从其调用程序路由至处理程序的方法。具体来说，路由事件是从幕后在命令调用程序和处理程序之间路由消息（通过将其挂接至可视树中的命令绑定）。
这样，众多元素间都存在关联，但在任何时刻都实际只有一个命令处理程序处于活动状态。活动命令处理程序由可视树中命令调用程序和命令处理程序的位置、以及 UI 中焦点项的位置共同决定。路由事件用于调用活动命令处理程序以询问是否应启用命令，并调用命令处理程序的 Executed 方法处理程序。
通常，命令调用程序会在自己在可视树中的位置与可视树根项之间查找命令绑定。如找到，绑定的命令处理程序会确定是否启用命令并在调用命令时一并调用其处理程序。如果命令挂接到工具栏或菜单中的一个控件（或将设置FocusManager.IsFocusScope = true 的容器），则会运行一些其他的逻辑，沿可视树路径从根项到命令绑定的焦点元素进行查看。
在图 3 的简单应用程序中，实际发生的情况是：由于 Cut 命令按钮位于工具栏内，所以由具备焦点项的 TextBox 实例处理 CanExecute 和 Execute。如图 3 中的文本框包含在用户控件之内，您就有机会对窗口、包含 Grid 的用户控件、包含文本框的用户控件或单个文本框设置命令绑定。有焦点项的文本框将确定其路径的终点（它的起点是根项）。
要理解 WPF 路由命令的路由，需要认识到一旦调用一个命令处理程序，就不能再调用其他处理程序。因此，如果用户控件处理 CanExecute 方法，就不会再调用 TextBox CanExecute 实现。
定义命令
ApplicationCommands.Save 和ApplicationCommands.Cut 是 WPF 提供的诸多命令中的两个命令。图 4 中显示了 WPF 中五个内置命令类及其所包含的一些命令示例。
图 4 WPF 命令类
|
命令类 |
示例命令 |
|
ApplicationCommands |
Close、Cut、Copy、Paste、Save、Print |
|
NavigationCommands |
BrowseForward、BrowseBack、Zoom、Search |
|
EditingCommands |
AlignXXX、MoveXXX、SelectXXX |
|
MediaCommands |
Play、Pause、NextTrack、IncreaseVolume、Record、Stop |
|
ComponentCommands |
MoveXXX、SelectXXX、ScrollXXX、ExtendSelectionXXX |
XXX 代表操作的集合，例如 MoveNext 和 MovePrevious。每一类中的命令均定义为公用静态（在 Visual Basic® 中共享）属性，以便您可轻松挂接。通过使用以下方式，您可以轻松定义自己的自定义命令。稍后我会提供相应的示例。
您也可搭配使用一个简短的注释，如下所示：
<ButtonCommand="Save">Save</Button>
如您使用此缩写版本，WPF 中的类型转换器将尝试从内置命令集合找到命名的命令。在此例中结果完全相同。我倾向于使用长名版本，这样代码更为明确、更易维护。不会对命令的定义位置产生歧义。即使是内置命令，在 EditingCommands类和 ComponentCommands 类之间也会有一些重复。
命令插入
路由命令是 WPF 所定义的 ICommand 界面的一种特殊实现。ICommand 的定义如下：
public interface ICommand {
event EventHandler CanExecuteChanged;
bool CanExecute(object parameter);
void Execute(object parameter);
}
内置的 WPF 命令类型为 RoutedCommand 和 RoutedUICommand。这两种类均实现 ICommand 界面并使用我先前所介绍的路由事件执行路由。
我们期望命令调用程序调用 CanExecute 来确定是否启用任何相关的命令调用代码。命令调用程序可通过订阅CanExecuteChanged 事件来确定何时调用该方法。在 RoutedCommand 类中，根据状态或 UI 中焦点项的变化触发CanExecuteChanged。调用命令时，会调用 Executed 方法并通过路由事件沿可视树分派至处理程序。
支持 Command 属性的类（如 ButtonBase）实现 ICommandSource 界面：
public interfaceICommandSource {
ICommand Command { get; }
object CommandParameter { get; }
IInputElement CommandTarget { get; }
}
Command 属性在调用程序和它将调用的命令之间建立关联。CommandParameter允许调用程序在调用命令的同时传递某些数据。您可使用 CommandTarget 属性根据焦点项的路径替换默认路由，并通知命令系统使用指定的元素做为命令处理程序，而不是依赖路由事件和命令处理程序基于焦点项所做的决定。
路由命令的局限
路由命令非常适合单用户界面，挂接工具栏和菜单项以及处理与键盘焦点项目（如剪贴板操作）相关的条目。但是，如果您要构建复杂的用户界面，即命令处理逻辑位于视图定义的支持代码之内，且命令调用程序不总是在工具栏或菜单之内，在这种情况下，路由命令就显得力不从心了。使用 UI 复合模式时，如 Model View Controller 或 MVC (msdn.microsoft.com/magazine/cc337884)、Model View Presenter 或 MVP (msdn.microsoft.com/magazine/cc188690)、Presentation Model，在 WPF 循环中亦称做 Model View ViewModel (msdn.microsoft.com/library/cc707885)，通常会出现这种情况。
此时的问题是启用并处理命令逻辑可能不是直接归属于可视树，而是位于表示器或表示模型。此外，确定是否启用命令的状态与命令调用程序和视图在可视树中的位置无关。有时，您会遇到一个特殊命令在给定时间有多个处理程序的情形。
要了解在哪些情况下路由命令会出现问题，请查看图 5。它是一个简单的窗口，包含一对用户控件，这两个控件以 MVP 或 MVC 模式表示视图。主窗口包含一个 File 菜单和工具栏，其中有 Save 命令按钮。在主窗口上方还有一个输入文本框，以及一个将 Command 设为 Save 的 Button。
图 5 复合用户界面（单击图像可查看大图）
提示：挂接匿名方法
在图 6 所示的代码中，我使用了我同事 Juval Lowy 传授给我的技巧，向声明中的委托挂接一个空的匿名方法。
Action<string>m_ExecuteTargets = delegate { };
这样，在调用委托前，您就不必再检查是否有空值，因为在调用列表中始终都有一个 no-op 订户。您还可能通过在多线程环境中取消订阅避免可能的争用，如果您检查空值，经常会出现争用。
有关此技巧的详细信息，请参阅 Juval Lowy 撰写的《Programming .NET Components, Second Edition》。
UI 的其余部分由两个视图提供，每个都是简单用户控件的实例。每个用户控件实例的边界颜色各不相同，这是为更清楚地显示它们所提供的 UI 内容。每个用户控件实例都有一个 Save 按钮，它将 Command 属性设为 Save 命令。
路由命令（与可视树中的位置密切相关）带来的困难在这一简单示例中一览无余。在图 5 中，窗口本身没有针对 Save 命令的CommandBinding。但它的确包含该命令的两个调用程序（菜单和工具栏）。在此情形中，我不想让顶层窗口在调用命令时必须了解采取何种操作。而是希望由用户控件表示的子视图处理命令。此例中的用户控件类有针对 Save 命令的 CommandBinding，它为CanExecute 返回 true。
但在图 5 中，您可以看到焦点项位于顶部文本框的窗口内，而此级别的命令调用程序却被禁用。此外，尽管用户控件中没有焦点项，但用户控件中的 Save 按钮却被启用。
如果您将焦点项从一个文本框更改到一个用户控件实例内，菜单和工具栏中的命令调用程序会变为启用状态。但窗口本身的 Save 按钮不会变为启用状态。实际上，在这种情况下无法用正常路由启用窗口上方文本框旁的 Save 按钮。
原因仍与单个控件的位置相关。由于在窗口级没有命令处理程序，尽管焦点项位于用户控件之外，但可视树上方或焦点项路径上仍没有命令处理程序会启用挂接为命令调用程序的控件。因此一旦涉及这些控件，会默认禁用命令。但是，对于用户控件内的命令调用程序，由于处理程序在可视树的位置靠上，所以会启用命令。
一旦您将焦点项转到其中一个用户控件内，位于窗口和焦点项路径上文本框之间的用户控件即会提供命令处理程序，用于为工具栏和菜单启用命令，这是因为它们会检查焦点项路径以及其在可视树中的位置与根项之间的路径。由于窗口级按钮和根项之间没有处理程序，所以无法启用该按钮。
要是这个简单的小示例中的可视树和焦点项路径的繁文缛节就让您倍感头疼，如果 UI 相当复杂，在可视树中众多不同位置有命令调用程序和处理程序，要想理顺命令启用和调用有多难就可想而知了。那会您联想起电影《Scanners》中的怕人情节，让人头昏眼花。
避免命令出错
要防止路由命令出现与可视树位置相关的问题，您需要保持简洁。通常应确保命令处理程序位于相同的元素，或在可视树中处于调用命令的元素上方。您可以从包含命令处理程序的控件使用CommandManager.RegisterClassCommandBinding 方法，在窗口级加入命令绑定，这样就能实现上述目标。
如果您实现的是本身接受键盘焦点项（像文本框）的自定义控件，那么属于例外情况。在这种情形下，如果您想在控件本身嵌入命令处理且该命令处理仅在焦点项处于您的控件上时产生关联，您可实现这一目标，它的工作状况类似先前所示的 Cut 命令示例。
您也可通过CommandTarget 属性明确指定命令处理程序来解决上述问题。例如，对于图 5 中从未启用过的窗口级 Save 按钮，您可将其命令挂接更改为如下所示：
<ButtonCommand="Save"
CommandTarget="{BindingElementName=uc1}"
Width="75"Height="25">Save</Button>
在此代码中，Button 专门将其 CommandTarget 设为 UIElement实例，该实例中包含一个命令处理程序。在本例中，它指定名为 uc1 的元素，该元素恰好为示例中两个用户控件实例之一。由于该元素有一个始终返回CanExecute = true 的命令处理程序，窗口级的 Save 按钮始终处于启用状态，并仅调用该控件的命令处理程序，无论调用程序相对于命令处理程序的位置如何都是如此。
超越路由命令
由于路由命令存在一定的限制，许多用 WPF 构建复杂 UI 的公司已转为使用自定义 ICommand 实现，这些实现能为它们提供自己的路由机制，特别是与可视树无关联且支持多个命令处理程序的机制。
创建自定义命令实现并不困难。针对类实现 ICommand 界面后，会为挂接命令处理程序提供一种方式，然后可在调用命令时执行路由。您还必须确定使用何种标准确定引发CanExecuteChanged 事件的时机。
创建自定义命令时最好先使用委托。委托已支持调用目标方法，并支持多个订户。
图 6 显示了名为StringDelegateCommand 的命令类，它使用委托来允许挂接多个处理程序。它支持向处理程序传递字符串参数，并使用调用程序的CommandParameter 确定向处理程序传递的消息。
图 6 自定义命令类
public classStringDelegateCommand : ICommand {
Action<string> m_ExecuteTargets =delegate { };
Func<bool> m_CanExecuteTargets =delegate { return false; };
bool m_Enabled = false;
public bool CanExecute(object parameter) {
Delegate[] targets =m_CanExecuteTargets.GetInvocationList();
foreach (Func<bool> target intargets) {
m_Enabled = false;
bool localenable = target.Invoke();
if (localenable) {
m_Enabled = true;
break;
}
}
return m_Enabled;
}
public void Execute(object parameter) {
if (m_Enabled)
m_ExecuteTargets(parameter != null ?parameter.ToString() : null);
}
public event EventHandler CanExecuteChanged =delegate { };
...
}
如您所见，我选择使用Func<bool> 委托挂接确定是否启用命令的处理程序。在CanExecute 实现中，类遍历挂接到m_CanExecuteTargets 委托的处理程序，查看是否有处理程序想执行的委托。如果有，它为要启用的StringDelegateCommand 返回 true。调用 Execute 方法时，它仅需检查是否启用了命令，如启用，则调用所有挂接到m_ExecuteTargets Action<string> 委托的处理程序。
要将处理程序挂接到CanExecute 和 Execute 方法，StringDelegateCommand类公开图 7 中所示的事件访问器，从而允许处理程序从基础委托轻松订阅或取消订阅。注意，您还可以在处理程序订阅或取消订阅时使用事件访问器触发CanExecuteChanged 事件。
图 7 命令事件访问器
public eventAction<string> ExecuteTargets {
add {
m_ExecuteTargets += value;
}
remove {
m_ExecuteTargets -= value;
}
}
public eventFunc<bool> CanExecuteTargets {
add {
m_CanExecuteTargets += value;
CanExecuteChanged(this, EventArgs.Empty);
}
remove {
m_CanExecuteTargets -= value;
CanExecuteChanged(this, EventArgs.Empty);
}
}
路由处理程序示例
在代码下载的示例应用程序中，我挂接了这个类。该示例有一个简单视图，隐含一个表示器（沿用 MVP，但没有模型）。表示器向视图公开一个表示模型以绑定数据（您可将表示模型想象成位于表示器和视图之间，而 MVP 模型位于表示器之后）。表示模型通常公开视图可以绑定数据的属性。在本例中，它仅公开了一个命令属性，以便可以通过数据绑定在视图的 XAML 中轻松实现挂接。
<Windowx:Class="CustomCommandsDemo.SimpleView" ...>
<Grid>
<Button Command="{BindingCookDinnerCommand}"
CommandParameter="Dinner isserved!" ...>Cook Dinner</Button>
<Button Click="OnAddHandler"...>Add Cook Dinner Handler</Button>
</Grid>
</Window>
Binding 声明只查找当前DataContext 的属性（名为CookDinnerCommand），如找到，则将它传给 Icommand。我们在前面提到过 CommandParameter，调用程序可以用它随同命令传递某些数据。在本例中，请注意我只传递了将通过StringDelegateCommand 传递给处理程序的字符串。
此处所示为视图的代码隐藏（Window 类）：
public partial classSimpleView : Window {
SimpleViewPresenter m_Presenter = newSimpleViewPresenter();
public SimpleView() {
InitializeComponent();
DataContext = m_Presenter.Model;
}
private void OnAddHandler(object sender,RoutedEventArgs e) {
m_Presenter.AddCommandHandler();
}
}
视图构建其表示器，从表示器取得表示模型，然后将其设置为DataContext。它还有按钮 Click 的处理程序，该处理程序调入表示器，让它为命令添加处理程序。
复合事件和命令
今年我一直在与 Microsoft模式和实践小组合作，帮助为 WPF 开发复合应用程序指南，这组指南用于在 WPF 中开发复杂的复合应用程序。其中包含称为 CompositeApplication Libraries (CAL) 的库，为复合应用程序提供服务和帮助程序类。
Glenn Block 的文章“使用 WPF 构建复合应用程序的模式”中有“WPF 复合应用程序指南”的更多信息，网址为 msdn.microsoft.com/magazine/cc785479。
图 8 显示了运行中的这一应用程序。第一个窗口处于初始状态，未挂接命令处理程序。由于没有命令处理程序，所以您会看到第一个按钮（调用程序）被禁用。按第二个按钮时，它会调入表示器并挂接新的命令处理程序。此时会启用第一个按钮，您再单击它时，它会调用其通过数据绑定松散联接的命令处理程序和基础命令的订户列表。
图 8 运行中的自定义命令示例（单击图像可查看大图）
表示器代码如图 9 中所示。您可以看到表示器构建了表示模型，并通过 Model 属性将其公开给视图。从视图调用 AddCommandHandler 时（响应第二个按钮 Click 事件），它会向模型的CanExecuteTargets 和ExecuteTargets 添加一个订户。这些订阅方法是表示器中的简单方法，它们分别返回 true 并显示 MessageBox。
图 9 表示器类
public classSimpleViewPresenter {
public SimpleViewPresenter() {
Model = new SimpleViewPresentationModel();
}
public SimpleViewPresentationModel Model {get; set; }
public void AddCommandHandler() {
Model.CookDinnerCommand.CanExecuteTargets+= CanExecuteHandler;
Model.CookDinnerCommand.ExecuteTargets += ExecuteHandler;
}
bool CanExecuteHandler() {
return true;
}
void ExecuteHandler(string msg) {
MessageBox.Show(msg);
}
}
本例显示数据绑定、UI 模式和自定义命令的组合将为您带来清晰独立的命令途径，可以摆脱路由命令的限制。由于命令是通过绑定以 XAML 形式挂接的，您甚至可以通过此方式完全用 XAML 定义视图（没有代码隐藏）、从 XAML 使用绑定命令触发表示模型中的操作、启动您原本需要表示模型代码隐藏执行的操作。
您需要控制器来构建视图并为其提供表示模型，但您不用代码隐藏就能编写交互视图。如果无需代码隐藏，在代码隐藏文件中添加相互纠结、不可测试的复杂代码的机率会大大降低，在 UI 应用程序中，这种情况经常出现。此方式刚在 WPF 中试用。但它的确值得考虑，您应该了解更多的示例。
Brian Noyes 是 IDesign (www.idesign.net) 的首席架构师、Microsoft 区域总监 (www.theregion.com)和 Microsoft MVP。他是《Developing Applications with Windows WorkflowFoundation》、《SmartClient Deployment with ClickOnce》和《DataBinding with Windows Forms 2.0》的作者。他还经常在全球行业会议上发表演讲。您可以通过 Brian 的博客 briannoyes.net 与他联系。
