基于PresentationModel的MVP和基于ViewModel的MVVM形式上一个主要区别在于前者的PresentationModel里一般要注入一个IView实例，当然目的是解耦，但也给人留下一个余地，也就是说在没有更好办法做binding的时候，可以调用IView直接操作界面来做事，当然是比较灵活的，而且基于接口依赖的UI与业务逻辑的分离也是不错的，但这需要维护View和PresentationModel之间的双向引用，而且代码（尤其是View的代码）看起来就不那么简洁了，因为即使是依赖于接口，也是依赖，总不如没有依赖要好；而后者（MVVM）的一个主要特征是：完全通过binding机制，由ViewModel指示UI如何做变更，同时用户与ViewModel的交互通过Command来实现，这样只需要View指导ViewModel即可，而ViewModel完全不必关心View暴露出什么样的接口和操作，它只需要提供属性(要绑定的数据和Command）并实现INotifyPropertyChanged即可，少了一个方向的依赖，代码自然更简洁清晰。
当然，作为一种通用的表示层模式，MVVM适用于各类客户端，比如Web, WinForm等等，但MVVM只有在WPF或Silverlight这种高级的UI技术支持下才能充分发挥它的优点。
Binding并不是非常符合直觉的一种手段，即使在winform里，有BindingSource做桥梁，binding显得很直观，但也不是谁都用得习惯的，而WPF里的binding配合DataContext、Converter、DataTemplate,、Style、以及各自对应的trigger，几乎无所不能，而且十分优雅，只是门槛较高，初学者不易充分理解（一个看法是：WPF这种markup方式的UI技术，很难“完全”照搬其他UI技术的经验，无论是winform，web，甚至同种类型的flex，想要充分利用WPF的好处，学习和实践的过程是必不可少的，而且学习曲线比较陡峭。并不是因为它有多难，而是因为有很多观念和习惯都需要转变，而且WPF所涉及到的技术方面太多太杂，但学习所花时间是值得的，未来的趋势在RIA，主流RIA开发技术大同小异，早晚要学，不如早学，学一个WPF还赚一个Silverlight。经常看到有人说WPF很简单，一学就会，看看代码才知道原来就是拿WPF当WinForm用，而且不伦不类，暴殄天物哦！其实会不会用WPF跟你原本是不是高手无关。）。另一方面，Command机制也在某种程度上避免了基于事件机制的限制，尤其是配合DelegateCommand和CompositeCommand（见Prism），可以有效地、优雅地在UI与controller之间解耦。 所以，如果想充分利用MVVM的好处，就要忍住不用IView，尝试完全用Binding和Command解决问题，这样憋一段时间，对WPF和Silverlight的理解自然就会上一个台阶， 正如书读百遍其义自见的道理。看到原本繁复传统的代码变得优雅现代，真让人心情舒畅。
