理解MVC、MVP、MVVM架构模式

       本文将阐述一下我个人对MVC、MVP、MVVM模式的定义和理解，能力有限，如有错误请指正。

前言

       软件架构模式从最开始的MVC模式，演化到MVP，然后到现在的MVVM，在不断的演化过程中其核心的思想就是降低各部分的耦合，让数据流向更加清晰。需要注意的是，并不是说MVVM比MVP更高级或者MVP比MVC更高级，只是对于软件的架构方式有不同的视角，针对不同的场景有了更多的选择方案。在学习过程中通过对三种架构方式的比对和思考，可以很好的帮助我们提高对于软件架构的理解。
       在开始之前，我们要先理解什么是架构，好的架构有什么作用？在网上看各种资料的时候发现真的是一万个人有一万个哈莫雷特，在这里谈谈我个人的理解：我们可以通过计算机硬件结构设计来理解软件架构，试想假如计算机所有部件都是焊在主板上的话，如果某个部件坏了，更换或者维修会有很大麻烦。而如果部件和主板的连接方式都是现代PC这样通过接口相连，那么如果有部件损坏，只需要将损坏的零件拔下换成新的即可，这样的设计显然是科学很多的。软件架构也是同样的道理，一个优秀的软件架构能大大降低后期变更和维护的难度。

       不同的架构模式有着不同的软件组织方式，并不一定是说哪一个最好，而是根据使用场景来选择最合适的架构模式。

MVC模式

       MVC的是Model（模型）-View（视图）-Controller（控制器）的缩写，其中Model保存相关数据，View直接与用户交互，Controller处理业务逻辑。三者关系如下：

       View将用户操作交给Controller，Controller根据用户操作处理逻辑并修改Model，Model通知View模型发生变化，View重新渲染，最终用户得到反馈。
       不难看出MVC模式有一个很大的问题，View层直接和Model层交互，两层耦合度很高。如果不能将View和Model解放出来，View层和Model层分别开发的交流成本就会非常大，这不符合我们“关注点分离”的思想。举一个简单的例子，假设类A和类B存在数据耦合（共用一个变量），那么让不同的开发人员对类A和类B进行分离式开发就变得非常困难，很显然交流成本太高。
       为了解决这个问题，MVP应运而生。

MVP模式

       MVP是MVC模式的变体，使用Presenter代替Controller，并且改变了数据的流向，从根本上消除了视图和模型的耦合，如图。

       这样一来，当View接收到用户操作，需要更新数据时，经Presenter通知Model来进行数据更新。同样的当数据发生更新时，Model也通过Presenter来告知View重新渲染页面。现在的View层非常薄，不包含任何业务逻辑，被称为“被动视图”，而Presenter会变得比原来更加臃肿，因为MVC模式是在View监听Model的变化来更新视图，而MVP模式视图的更新需要Presenter对View进行DOM操作。
       为了缓解这种臃肿，MVVM出现了。

MVVM模式

       MVVM是MVP的改进，用ViewModel代替Presenter，并且通过双向的数据绑定来实现View和ViewModel的交互（所谓双向绑定，就是View的变化能实时反映在ViewModel上，反之同理），如图。

       这样做最大限度地保证了View和Model分离的同时，还减轻了原本Presenter的压力，MVVM将一部分逻辑放在了View层，如：Vue的v-if（条件渲染）、v-for（列表渲染），Angular的ng-if、 ng-for等。


以上是我个人对三种模式的理解，如有错误还请大牛指正，如有不同意见也欢迎质疑，希望对大家有所帮助。