简述MVC、MVP和MVVM
前言
最近在看项目代码的时候，发现项目中用的MVC比较像MVP，在此对这几个相关设计框架做个简单笔记。
MVC
MVC，即Model-View-Controller。Model就是数据层，用于存储和管理数据；View就是显示层，提供纯显示上的接口；Controller就是控制层，提供逻辑控制接口，更新数据，更新显示。三者可以均可交互。
MVC将用户输入统一放在控制层进行处理，方便进行管理，并且数据层和显示层分离，使得代码更加纯粹，耦合度降低。但是一般情况下，一个View对应一个Controller，这样View就无法抽象复用，增加了大量冗余代码。除此之外，显示层需要直接获取数据层的数据进行显示，所以还是存在一定的三方互相耦合。
那么如何进行优化，解决MVC的问题呢？MVP的出现就解决了上述问题。
MVP
MVP，即Model-View-Presenter。Model就是数据层，用于存储和管理数据；View就是显示层，提供纯显示上的接口；Presenter就是控制层，提供逻辑控制接口，更新数据，更新显示。但是跟MVC不同的是，在MVP中，显示层只能和控制层交互，数据层也只能和控制层交互。也就是说，控制层在MVP中就像是一个中间人，显示层需要调用控制层的接口来获取数据层的数据。
MVP的优势就在于，数据层和显示层完全解耦，双方完全不知道对方的存在。也正是因此，显示层可以非常方便地抽象出来。但是由于显示层每次都需要通过控制层来获取数据层的数据，特别麻烦，代码量会增多，可读性会变差。
那么如何进行优化，解决MVP的问题呢？MVVM的出现就解决了上述问题。
MVVM
MVVM，即Model-View-ViewModel。Model就是数据层，用于存储和管理数据；View就是显示层，提供纯显示上的接口；ViewModel就是控制层，用于将显示层的各个显示和数据层的各个数据进行一一绑定。
所谓绑定，即当数据层更新时，自动反馈到显示层；当显示层更新时，自动反馈到数据层。MVVM这种机制减少了MVP中手动去获取数据、手动去更新数据的操作。虽然在实现上MVVM非常像MVP，但是它们的中间层，即控制层，所起的作用不太一样，给开发者带来的便利程度也不一样。
小结
从MVC到MVP再到MVVM，是一个逐渐演变的过程。这三种设计框架并不能说出个绝对的好与坏，都各有利弊，需要根据实际项目来进行选择。虽然看上去MVVM开发者进行开发比较方便，代码量比较少，但是整个框架并不轻量。
各种模型设计出来最大的目的就是为了解耦，减少各个模块之间的相互依赖，减少“胶水”代码。当然，解耦的同时肯定会面临着跳转增加、代码可读性变差等问题。但是，所换来的高维护性是各个大型项目中非常必要的。
很多时候，为了追求所谓的设计模式，把代码设计得过于复杂，极大增加了开发的工作量和难度，这反倒有些本末倒置了。所以说，如何合理平衡设计模式和代码简单易开发，是需要好好思考的一个问题。
参考
上述图片来源。