这里的“命令”即Command模式中的“Command”，几乎每个应用程序都有该模式的运用，如何“复制”“粘贴”“撤销”等操作。我们知道，该模式将操作的请求者和操作的执行逻辑隔离开来，并且其对请求排队以及撤销重复等操作有着良好的支持，所以被广泛应用。而WPF将其做了进一步的封装和改进，使得WPF程序能够很容易地使用命令和打造自定义命令，另外，WPF内置的数十种常用命令以及先进的命令路由模式（Routed）使得这一切显得那么容易和高效。
那么是不是WPF命令（RoutedCommand和RoutedUICommand）足以解决一切情况了呢？并非如此，事实上其有着许多的不足，这也就是为什么Prism要打造一套自己的Command的原因。本文将简单探讨一下这些问题。
-------------------------------WPF 的 Command----------------------------
1，理解WPF RoutedCommand中的“Routed”（路由）
WPF提供了RoutedCommand和RoutedUICommand两种命令，其中RoutedUICommand继承于RoutedCommand，翻开MSDN，我们可以看到这样的解释“其定义一个实现 ICommand 并通过元素树路由的命令，RoutedCommand 上的 Execute 和 CanExecute 方法不包含命令的应用程序逻辑（例如，一个典型的 ICommand 就是这样），而是将引发遍历元素树的事件以查找具有 CommandBinding 的对象。 附加到 CommandBinding 的事件处理程序包含命令逻辑。” 这就是所谓的“路由”：其会在特定的元素树（实际是视觉树）路径上查找CommandBinding，然后去调用CommandBinding的CanExecute和Execute来判断是否可执行以及如何执行命令。那么该路径是怎样的呢，请看下面的例子：
上面两幅图中的各按钮代码形如
<Button Command="Copy" Content="{Binding Path=Command.Text, RelativeSource={RelativeSource Self}}"/>
首先看第一幅图，当文本框（TextBox）中的文本被选中时，工具条上的“复制”按钮被启用了，而文本框右边的按钮却没有被启用；
在第二幅图中，FlowDocument中的文本被选中时，FlowDocument中的按钮和工具栏上饿按钮都被启用了。而文本框旁边的按钮始终都得不到启用。