最后一个引起了大家的注意，非常感谢。因为我自己对这些模型的理解是有限的，这些模型的对比是基于我自己的理解，有些地方不一定准确，但是只有展示我自己的观点才能吸引更多的关注？欢迎拍砖。)复制代码如下：阅读目录：四。MVP模式4.1 MVP理念4.2 UI界面4.3 Presenter ——模型和视图之间的桥梁4.4 MVP代码结构和时序图4.5 MVP模式总结5.1 MVVM模式设计理念5.2 MV。虚拟机模式结构图。MVC、MVP和MVVM模式使用场景总结四。MVP模式MVP模式也是一种经典的界面模式。在MVP中，m代表Model，V代表view，p代表Presenter。下面例子中的完整代码可以从： WinformMVP的源代码中下载。也可以对比这篇文章，分析MVP模式下的V-P交互问题，分享4.1 MVP的思路。在我看来，MVP模式是一种真正隔离View细节和复杂性的模式。为什么说：因为在其他模式下，v代表UI界面，是html页面、XAML文件或者winform界面？但是MVP模式下的V代表一个接口，一个从UI接口抽象出来的接口。接口意味着任何实现该接口的接口都可以重用现有的演示者和模型代码。4.2 UI界面要想很好的理解MVP，必须要有UI界面的能力。看下面的界面，抽象出用红色标注的User Control，就可以得到下面的界面。

4.5 MVP模式总结在MVP中。Presenter将Model和View完全分离，主程序逻辑在Presenter中实现。再者，Presenter与具体的View没有直接关系，而是通过定义好的接口进行交互，这样在更改View时Presenter就可以保持不变，也就是重用！不仅如此，我们还可以编写View进行测试，模拟用户的各种操作，从而在不使用自动化测试工具的情况下实现Presenter的测试——。即使模型和视图都不完整，我们也可以通过编写Mock Object来测试Presenter逻辑(即实现了模型和视图之间的接口，但没有具体的内容)。MVP的优势：1。模型与视图完全分离，因此我们可以在不影响模型的情况下修改视图；2.我们可以更有效地使用模型，因为所有的交互都发生在一个地方——Presenter3.我们可以将一个演示者用于多个视图，而无需更改演示者的逻辑。这个特性非常有用，因为视图总是比模型变化更频繁。4.如果我们把逻辑放在Presenter中，那么我们就可以在没有用户界面(单元测试)的情况下测试这些逻辑。5.MVVM模式5.1 MVVM模式的设计思路。在MVVM模式下，视图模型与视图匹配，视图在MVP中没有IView接口，但完全绑定到视图。视图中的所有修改和更改都将自动更新为视图模型，视图模型中的任何更改都将自动同步到视图中进行显示。之所以能够实现这种自动同步，是因为ViewModel中的所有属性都实现了一个像observable一样的接口，也就是说当使用属性的set方法时，会同时触发属性修改的事件，从而自动刷新绑定的UI。(在WPF，这个可观察的接口是INotifyPropertyChanged在knockoutjs中，是通过ko.observable()和ko.observrableCollection()实现的。)所以，MVVM比MVP高了一步。在MVP中，V是IView的接口，解决了与UI的耦合。而MVVM只是简单的使用了视图模型和UI的无缝结合，视图模型可以直接表示UI。然而，MVVM依赖于特定的平台和技术来实现这一点，例如WPF和knockoutjs，这就是为什么ViewModel不需要实现接口，因为依赖于特定的平台和技术。本质上，使用MVVM模式是不能替代UI的使用平台的5.2 MVVM模式结构图。下面是MVVM模式结构图，可以帮助更容易理解MVVM模式：。

不及物动词MVC、MVP、MVVM使用场景总结。因为winform不能像WPF一样支持数据和接口的双向绑定以及事件监控，所以MVP是winform中最好的选择。WPF和html接口使用淘汰赛实现可观察，所以使用MVVM。(应该说，WPF是为MVVM设计的。)在web应用中，由于http基于请求和响应协同工作，不能始终保持连接状态，因此无法实现MVC中Presenter之间的消息传输和MVVM的ViewModel与接口之间的绑定，因此MVC是最佳选择。