理想的MVC模式中VC之间没有直接依赖（没有单向依赖），但现实中做不到。Native应用要一般由View分发事件给Controller，Controller要决定那些View用户可见。
Web应用中情况好一点。用户可以直接通过url直接访问Controller，不需要View知道Controller，但是Controller还负责路由View。前端复杂化后，页面上与Controller交互更频繁，Controller也很难只通过url来实现了。
事实上MVC有三个问题：
1. V和M之间不匹配，用户界面和流程要考虑易用性，用户体验优化同时考虑业务流程的精确和无错。
2. C和M之间界线不清，什么样的逻辑是界面逻辑，什么样的逻辑是业务逻辑，很难定义清楚。
3. V的变化不能完全由Model控制，即Observer模式不足以支持复杂的用户交互。这其实要求VC之间要有依赖。
后来的MVP与MVVM都是为了优化VC之间的关系而提出的。
MVP认为VC之间强绑定不可避免，但可以加强P的能力。V变成只显示，P提供数据给V，把双向依赖简化为P直接依赖于V。
由于V的数据由P提供，则MV之间的Observer关系转移到MP之间。
MVP主要解决1、3两个问题，但代价是加重了问题2，P更重，而且与Model耦合无法框架化。且实践中View很难完全被动化，它总是会随用户的事件变化，这部分成为P的负担。
而MVVM则是另一个方面来解决问题。MVVM认为View应该是事件驱动，模型变化只是一种事件。C应该只处理View与模型不配合的问题，而问题3可以通过分离用户交互与界面构造。C退化为一个View的模型VM，它与View之间由框架提供事件-数据的绑定。
MVVM与MVP相比主要彻底解决了问题1，重新定义了问题2，在MVVM中VM的功能比较明确，把M翻译成View需要的数据。VM有一定视图的属性，View与VM有对应关系，也就解决一部分问题3。但是由于各角色职责已经定义，需要引入第四个组件来解决这个问题。
我们可以打个分，直接依赖计为1，间接依赖计为0.5
- 全部互相依赖是6。
- 理想MVC，MV=1.5，MC=1,共2.5。
- 现实MVC根据VC之间的依赖情况可能是0.5~2，实际是3~4.5。
- MVP，MP=1.5，VP=1，MV=0，共2.5。与理想情况一致。
- MVVM，MVM=1.5，VM+V=0.5~1，共2~2.5，即不高于理想MVC。
原文出自阮一峰的博文（MVC，MVP 和 MVVM 的图示）评论区网友anthony发表的评论，经排版优化后发此博文记录。