简析MVC到MVP再到MVVM

开发中经常会被问到什么是MVC，什么又是MVP、MVVM，这里为大家简单的介绍一下这三者以及他们之间的关系。

随着计算机软件的发展，当需求变得庞大，解决方案也会变得庞大；当解决方案变得庞大，就会出现细分；当出现细分，就会出现按哪种方式管理的问题。软件从处理一件事务发展到了要处理许多事务，各事务间有包含、顺序、主次等等的关系，变得越来越复杂。因为数据与逻辑庞大了，所以数据与逻辑就分离了，然后时间和业务分离了。应用而生了各种模式。

首先介绍MVC，Model+view+controller,其中界面分到了view，数据分到了model，业务集中在controller中，推动业务的事件由用户与view交互，通过view与controller发动。



MVC的一般流程为：

view（界面）触发事件--->Controller(业务)处理了业务，然后触发了数据更新--->更新Model数据--->Model(带着数据)回到view--->view更新数据。

MVC的不足之处：

当有变化的时候，我们需要同时维护三个对象和三个交互，这显然是让事情复杂化了。MVP的出现刚好就优化了MVC模式或者说替代了它。

MVP：Model+View+Presenter

其中presenter就类似于MVC中的controller，进行业务逻辑处理。

                                                                        


如图所示，MVP切断了view和model之间的联系，让view只和presenter交互，减少了需求变化的时候维护对象的数量。MVP定义了view和presenter之间的接口，让一些可以根据已有的接口协议去各自分别独立开发。比如，presenter中的逻辑处理结果有5种不同的，那么他会提供五个接口对应的view会有相应的5中不同的布局，那么view会根据不同的结果展示不同的布局。

MVVM:Model+view+viewModel

viewModel大致就相当于MVP的presenter和MVC的controller，进行业务逻辑处理。

                                                                   


如图，view和viewHolder之间没有了MVP之间的界面接口，而是直接交互的，用数据绑定的形式，让数据更新的事件不需要开发人员动手编写特殊用例而是自动的双向同步。其中数据绑定可以认为是observer观察者设计模式。

至此，比起MVP，MVVM不仅简化了业务界面的依赖关系，还优化了数据频繁更新的解决方案。