浅析WPF中MVVM模式下命令与委托的关系

??各位朋友大家好，我是Payne，欢迎大家关注我的博客，我的博客地址是http://qinyuanpei.com。最近因为项目上的原因开始接触WPF，或许这样一个在现在来讲显得过时的东西，我猜大家不会有兴趣去了解，可是你不会明白对某些保守的项目来讲，安全性比先进性更为重要，所以当你发现银行这类机构还在使用各种“复古”的软件系统的时候，你应该相信这类东西的确有它们存在的意义。与此同时，你会更加深刻地明白一个道理：技术是否先进性和其流行程度本身并无直接联系。由此我们可以推论出：一项不流行的技术不一定是因为它本身技术不先进，或许仅仅是因为它无法满足商业化的需求而已。我这里的确是在说WPF,MVVM思想最早由WPF提出，然而其发扬光大却是因为前端领域近年来比较热的AngularJS和Vue.js，我们这里表达的一个观点是：很多你以为非常新潮的概念，或许仅仅是被人们重新赋予了新的名字，当你理清这一切的来龙去脉以后，你会发现这一切并没有什么不同。这符合我一贯的主张：去发现问题的实质、不要被框架束缚、通过共性来消除差异，所以在今天这篇文章里，我想说说WPF中MVVM模式下命令与委托的关系。

什么是MVVM/h2>

??接下来，我们为了彻底地让视图和模型分离，我们发明了新的软件架构：MVP。虽然从感性的认识上来讲，它是将Controller改名为Presenter，然而从理性的认识上来讲，它在让视图和模型分离这件事情上做得更为决绝果断。通过图示我们可以发现，视图和模型不再发生直接联系，它们都通过Presenter相互联系，而且各个部分间的通信都变成了双向流动。我们可以很快意识到，现在全新的控制器即Presenter会变得越来越“重”，因为所有的逻辑都在这里，而视图会变得越来越“轻”，它不再需要主动去获取模型提供的数据，它将被动地接拥抱变化，因为现在在视图里基本上没有任何业务逻辑。现在我们可以预见，人类会在隔绝视图和模型这件事情上乘胜追击，人们会尝试让Controller/Presenter/ViewModel变得越来越臃肿，我想说的是，求它们在得知这一切真相时的心理阴影面积，我们试图让每一个模块各司其职、通力协作，结果脏活累活儿都交给了Controller/Presenter/ViewModel，我想说这件事情做的真是漂亮。

??这里需要说明的是CanExecuteChanged这个事件，这个和INotifyPropertyChanged接口中的PropertyChanged成员类似，是在当CanExecute发生变化的时候通知视图的，我对这里的理解是CanExecute本身就具备对某一个过程是否应该被执行的支持，可是遗憾的是在，在我参与的项目中，人们更喜欢声明大量的布尔类型变量来处理这里的相关逻辑，因此无论是对Property还是Command而言，在ViewModel里都是看起来非常丑陋的代码实现。

??好了，现在对我们而言，这是一个非常愉快的旅程，因为在完成对RelayCommand的定义以后，我们绑定命令和定义命令的过程是非常简单的。除此以外，WPF提供了一个RoutedCommand类，该类实现了ICommand接口，我怀疑MVVM light中的EventToCommand正是通过这种思路实现了路由事件到命令的转换，因为只有RoutedCommand具备访问UI事件的能力，这里我们仅仅提出问题，进一步的思考和验证我们可以留到以后去做。下面我们来看看如何声明和绑定命令：

显然这个ClickCommand将作为一个属性出现在ViewModel中，我选择了一个我最喜欢用的方法，或许这样看起来非常低端。可是在调试界面的过程中，它要比断点调试更为直接和直观。当我们的ViewModel中出现这样的只读属性的时候，直接在Get访问器中定义它的返回值似乎是最直接有效的方案，可问题是Get访问器应该是非常“轻”的，因为大量业务逻辑的渗透，现在连这里都不能保留其纯粹性了吗让我表示非常郁闷啊。

现在你可以发现，委托和命令结合得非常好，当你发现这一切如此美妙的时候，回归本质或许是我们最喜欢的事情，就像纯粹的你我一样，在这个世界上，我们彼此装点着各自生命里美好的风景，执著而勇敢、温暖而明媚，那些周而复始的日子里，总能听到梦想开花的声音。

小结

??在这篇文章里我们讨论了MVC、MVP、MVVM各自架构变迁的前因后果，由此我们知道了软件设计中，一个典型的设计目标是让视图和模型分离，可我们同样发现，带着这个目标去设计软件的时候，我们基本鲜有更换视图的时候，虽然从理论上来讲，所有的业务逻辑都是在ViewModel中，视图和模型应该是可以进行更换的，可是你告诉我，有谁会为同一个软件制作不同的界面呢道我们还能期望通过一个静态工厂，来为不同的平台返回不同的视图，然后理论上只要适配正确的控制器就可以实现软件对不同平台的“自适应”，可是软件开发领域发展至今，最有可能提供完整跨平台方案的Web技术目前都无法满足这个需求，所以我们是否应该去怀疑这个设计的正确性呢样的，以Java的SSH三大框架为代表的“配置文件”流派，认为应该将数据库的相关信息写在配置文件里，这样可以满足我们随时切换到不同数据库产品上的需要，可是你告诉我，这样的应用场景多吗以，技术本身的设计并没有问题，我们需要思考的是，是否应该被框架和架构束缚，说到底我们是为了设计出更棒的软件产品，以此为目标，其实框架和架构更应该衍生为一种哲学意义上的思想，我们想让每一行代码都充满智慧的光芒，它骄傲却不孤独，因为总有人理解它、懂它。