又看一下自定义的ExInvokeCommandAction类。

这个类的本质：它继承自TriggerAction，所以能和Xaml界面控件的事件绑定，就可以取代系统默认的事件响应方式。并且这个类中的普通属性被封装为依赖性属性，就可以和ViewlModel中的具体命令对象，以及view中的事件对象绑定。其实质就是把ViewModel中的对象带进了View中。让底层的自定义个性化命令，经过标准接口，跨越设计模式的隔离，在View中与界面元素相遇，并完成具体动作。

使用这个类的时候，首先要在ViewModel中，声明出各种ICommand类型的具体命令对象，做为标准接口暴露给UI。这些具体命令对象的形参，必须要匹配源自UI的参数对象的类型。

然后就可以把ExInvokeCommandAction对象，通过Xaml语法绑定到某个UI控件的某个事件，让自己成为这个事件的背后执行机制。

当这个特定事件发生的时候，这个ExInvokeCommandAction对象，会把某个ICommand类型的具体命令对象，通过依赖性属性传递到自己内部，还会把所需的某个界面对象做为参数，也通过依赖性属性传递到自己内部，然后在内部触发Invoke执行。在Invoke内部，界面参数对象被封装为特定格式，传递给特定的具体命令，最后执行这个命令。

这个设计套路审视起来似乎与完美的MvvM标准隔离原则有点不符，因为在界面中加载了底层对象，而这个加载不是通过标准接口进行的。虽然这个对象加载之后，会让UI元素增加绑定接口并扩展背后机制。

在Xaml环境中的Mvvm模式，编程体验上是看不到任何界面元素的背后实现的，在程序集中完全看不到相关代码，看不到designer。这些系统代码当然都存在，只是看不到而已，所以形式上很干净，低耦合。

现在自己做了一个类，并让它成为界面元素的背后机制。既然是背后机制，当然是不走表面的标准接口了。只是自己实现的界面类，是没法让其眼不见为净的。这是个程序集的管理问题，恒定的管理方式可以做为标准的基础。Winform中每个Form背后的designer也是这样的，只是数量多看着有点烦。

INotifyPropertyChanged类型的对象，ICommand类型的对象，再加上扩展的TriggerAction对象，基本上界面和底层之间的对象传递标准化就解决了。

采用MvvM设计模式的一个主要目的在于释放界面的设计创意。界面所需的一切底层信息都被抽象为标准接口集，这是一种封装。这和通常面向对象中常用的把数据对象封装为实体类是一样的，我们通常把这些实体类称为Model。同样道理，由界面View抽象出来的这种数据封装体，当然就叫ViewModel了。

最初触发自己这方面想法的，就是看到美国ICONICS的产品表现，那是靠Xaml实现的。3D、虚拟和增强现实等。Xaml和Xamarin跨平台，都需要这种界面分离的模式。好看好玩的软件才是好软件。之所以没选普遍流行的B/S开发模式，就是因为浏览器中开发不出这么炫的界面，只有客户端才行。当然，如果采用界面分离的模式，底层是稳定的，前脸无所谓是CS还是BS或其它。