MVC MVP MVVM

MVC，MVP，MVVM都是用来解决界面呈现和逻辑代码分离而出现的模式。

一.MVC、MVP、MVVM诞生的需求

我们所有的代码都是围绕数据的。

围绕数据的产生、修改等变化，出现了业务逻辑。

围绕着数据的显示，出现了不同的界面技术。

没有精心设计的代码常常会出现数据层（持久层）和业务层还有界面代码耦合的情况。

ORM等框架，降低了业务逻辑和数据之间的耦合，业务逻辑不再关心底层数据如何存储和读取。所有数据呈献给业务逻辑层的就一个个的对象。

MVC，MVP，MVVM就是用来解决业务逻辑和视图间的耦合的。

二、MVC模式

Model View Controller 模型视图控制器的缩写，MVC开始是存在桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式

3.1 主动MVC

model主动通知view更新

model：用于封装与应用程序的业务逻辑相关数据以及对数据的处理方法。模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，这些用于监视此模型的视图必须事先在此模式上注册，从而，视图可以了解数据模型上发生的改变

view：负责数据的展示。

在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型，因此应该实现在被它监视的数据那里订阅model事件

Controller：控制器是M和V之间的连接器，用于控制应用程序的流程。它处理事件并作出响应。事件包括用户的行为和数据模型上的变化。

3.2被动MVC

与主动MVC的区别是view没有订阅model数据变化的事件，等待model来通知需要根据新的数据来更新view，被动MVC中，Controller负责通知view，有数据变化，需要更新视图

被动MVC与主动MVC的区别

1、模型对视图和控制器一无所知，它仅仅是被它们使用

2、控制器使用视图，并通知它更新数据显示

3、视图仅仅是在控制器通知它去模型取数据的时候它才这么做

3.3web应用中的MVC框架

Web中的MVC框架都是被动MVC模式，因为web应用中，由于http是基于请求和响应方式协同工作的，因此当服务器端的model发生变化时，它不会立即更新客户端的view，只有客户端重新请求或刷新界面时才更新

3.4MVC总结

MVC优点

由于MVC很好地分离了视图层和业务层，所以它具有以下优点：

耦合性低

开发速度快

可维护性高

没有控件的概念，对HTML没有封装，易于理解

和其他平台等更加相似

误区：

1、把model理解成实体类，在MVC中Model应该包含2部分功能，一部分是处理业务逻辑，一部分是提供view显示的数据

2、把业务逻辑全部放在Controller端

Model在MVC架构中起的作用非常重要，它应该是业务逻辑真实地实现层。所以Model的实际上是business Model。而Controller仅仅起一个桥梁作用，负责把view的请求转发给Model，再负责把Model处理结束的消息通知view。Controller是用来解耦view和Model的，具体一点说，就是为了让UI与逻辑分离。

三、MVP模式

MVP模式也是一种经典的界面模式。MVP中的M代表Model，V是View，P是Presenter。

1、MVP的思想

MVP模式在我看来，是一个真正意义上的隔离View的细节和复杂性模式。为什么这么说：因为在其它模式中V代表的石UI界面，是一个html页面，XAML文件或者winform界面。但是在MVP模式中的V代表的是一个接口，一个将UI界面提炼而抽象出来的接口。接口意味着任何事先了该接口的界面都能够复用已有的Presenter和Model代码。

2、UI界面接口化

后端代码要获取界面上的输入框的值，只需要get属性，要更新界面显示的时候，就只需要set属性。

后端代码对于界面的操作，被抽象成了对于UserAge属性的操作了，也就是和具体的界面显示无关。

3、Presenter--Model和View之间的桥梁

P是Model和View之间的桥梁，负责将对应的Model和View组合到一起

4、MVP模式总结

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。我们甚至可以在Model和View都没有完成时候就可以通过编写mock Object来测试Presenter的逻辑。

5、MVP的优势

模式与试图完全分离，我们可以修改视图而不影响模型

可以更高效地使用模型，因为所有的交互都发生在一个地方--Presenter内部

我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。

如果我们把逻辑放在Presenter中，那么我们就可以脱离用户界面来测试这些逻辑

四、MVVM模式

设计思想：MVVM模式中，一个ViewModel和一个View匹配，它没有MVP中的IView接口，而是完全的和View绑定，所有View中的修改变化，都会自动更新到ViewModel中，同时ViewModel的任何变化也会自动同步到View上显示

这种自动同步之所以能够实现的原因是ViewModel中的属性都实现了observable这样的接口，也就是说当使用属性的set方法，都会同时触发属性修改的事件，使绑定的UI自动刷新。

所以MVVM比MVP更升级一步，MVP中，V是接口IView，解决对于界面UI的耦合；而MVVM干脆直接使用ViewModel和UI无缝结合，ViewModel直接就能代表UI。但是MVVM做到这点是要依赖具体的平台和技术实现的，比如WPF和knockoutjs，这也就是为什么ViewModel不需要实现接口的原因，因为对于具体平台和技术的依赖，本质上使用MVVM模式就是不能替换UI的使用平台的

五、MVC、MVP和MVVM模式使用场景总结

由于在winform中无法像WPF一样，支持数据和界面的双向绑定以及事件的监控，所以，在winform中MVP是最佳选择。

WPF和html界面中使用Knockout，实现了observable，所以使用MVVM。

在web应用中，由于http是基于请求和响应方式协同工作的，无法一直保持连接状态，所以无法达到MVP中Presenter之间的消息传递和MVVM中的ViewModel和界面之间的绑定，所以MVC是最佳的选择。