MVC、MVP和MVVM是三种用以实现软件系统中用户界面与逻辑层解耦的抽象架构模型，其中后两种算是MVC的变形。作为三种最常用的三种架构设计模式，它们有着各自不同的的应用场景，结合自己之前的经验，来简单总结下它们的特点。
在实际开发中，选用的架构可以看作是一种骨架，结合业务需求往往需要在骨架的基础上进行一些改造并丰富细节。
MVC
MVC（Model-View-Controller）模式主要分为三个部分，分别是模型、视图和控制器。
- 模型（Model）：处理底层业务逻辑，实现相关运算；
- 视图（View）：页面显示，完成与用户的交互；
- 控制器（Controller）：完成模型与视图的数据（或命令）通信，完成应用层面的相关任务；
从上图的通信流程图来看，三个模块间的通信是单向的，首先用户操作视图，传达相应的指令到控制器，控制器将指令解析，传递给模型进行相应的处理，如果需要将结果反馈给视图，则再将指令传递给视图，最终视图完成更新。
MVP
MVP(Model-View-Presenter)是从经典的MVC演变过来的，但是由于model和view之间不进行直接连接，而是将presenter作为桥梁，完成从view到model到数据传输，以及从model到view到界面更新。
它的特点总结是：
- 各部分之间的通信，是双向的；
- Presenter就是相对于MVC中的Controller，为了便于区分，将控制器命名为Presenter；
- Presenter可以对应多个view，控制接口后，能应对来自于view的复杂变化；
从结构上来看，mvp中因为view与model不直接通信，降低了整个系统的耦合程度，相比较mvc来说，view由于只被动地处理界面，因此被称为“被动视图”（Passive View），随之而来造成presenter的变重，除了要完成整个业务逻辑的实现，还要加上对view的控制。
MVVM
MVVM（Model-View-ViewModel），最大的区别是将控制器（controller/presenter）换成了ViewModel（VM），与之对应的VM在功能方面，也进行了更新。
从结构图来看，与MVP的变化不大，但对于VM来说，它与model采用双向绑定（data-binding）的形式，即如果View和ViewModel任意一方发生变化时，另一方会自动更新。
在多视图下的应用
考虑一种“复杂软件”的情况，即主视图（parent-view）下存在着多个子视图（child-view），每个视图之间的业务逻辑各不相同，但从界面的角度来说又各自关联，如何套用到上述的三种模型中呢？
以MVP模型举例，当然可以把多个视图抽象成一个整体，这样看就与前面的流程图差不多，但从模型和presenter的角度来说，它们会变得很臃肿且耦合度高（在presenter/model下，将所有view对应的指令和实现放在一起）。
在尽可能低耦合的目标下，可以针对每一个view，构建对应的model和presenter，其中presenter不单要完成模块内（与自身model和view）的指令传递，也要完成与其他模块（其他presenter）的通信，如下图所示：
如果这个复杂软件需要多个开发人员协作时，只要把presenter间的接口确定好，每个开发人员可以最大程度上专注于自己所负责模块的功能实现。
总结
最后以一句老生常谈的话作为总结：
适用于任何情况的架构设计模型是不存在的，只能在结合实际需求的情况下寻找或创造一种相对适合的模型。