MVC模式是"Model-View-Controller"的缩写，中文翻译为"模式-视图-控制器"。MVC应用程序总是由这三个部分组成。MVC模式出现历史较早，并且在基于各种技术实现和语言开发中被广泛的运用，可以说是深入人心。
在依据MVC基本模式构建移动开发产品时，阅读MVC的相关资料会发现有诸多差异，另外不同背景和经历的设计人员对其理解也多有不同。造成了大家对看似已经熟知的东西在理解上反而造成了困惑，产生了很多争议。
另外，作为从经典的模式MVC演变而来的MVP 也被大家广泛的关注，MVC与MVP究竟有何不同，我们构建的架构模式就是选用MVC还是MVP呢？
首先分析一下目前网络资料中所描绘的各种各样的MVC模式关系图。
留意上面的几张图，会发现两者主要的区别是model依赖View还是View依赖model，首先来说两种情况都是正确的MVC模式，只是在使用的场合和依赖于不同的技术实现。
- View依赖model：一般来讲我们把View定义为用户交互界面，View的处理仅限于视图上数据的采集和展示，以及用户的请求。那么为什么会有View访问Model的情况出现呢？了解ASP的binding和JSP的标签技术的开发者可能就释然了。
- Model依赖View：这种情况较为少见也是很多开发不能理解的地方。毕竟接触过EJBs和ColdFusion这样技术的人不多，使用ColdFusion能够使用输入模板建立一个内容数据库，然后将它与应用程序结合，建立一个动态网页（View）。
那么在进行IOS架构设计时，如何来理解MVC呢，我依据斯坦福大学的IOS公开课中关于MVC的解释。图中形象的使用交通规则线进行对MVC彼此访问关系进行表达，其中的关系一目了然。
虚线表示可以访问，实线表示禁止直接访问或不可以来，双黄线表示禁止访问。
接下来在此基础上我们看MVP的关系图。可以对于IOS开发来说MVP是一个更纯粹的MVC，或者说MVP等同于MVC两者没有区别。这也是网上资料中很少有资料将IOS和MVP关联在一起，大多是Android架构中经常提到MVP。
Android中使用MVP也是源于对View的基本概念理解不同，如果我们把布局文件作为View来理解那么MVC和MVP的就与IOS中概念相同没有区别了。目前的基于MVP架构在Android中使用时将Activity作为View的一部分于是就需要一个单独的Presenter来处理业务逻辑了。
总结
无论是不同的MVC模式图还是MVP其本质上是寻求【表示】【逻辑】【数据】三者的独立性，不同的概念和对概念的理解不同产生于不同的使用场景和技术实现。在进行架构模式选择也要遵循这两点基本要求，没必要在概念层层次争论不休，同时也要记住那句老话尽信书不如无书。
