一. MVC模式
MVC全名Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
Web应用中的MVC框架
Web中的MVC框架都是被动MVC模式，因为web应用中, 由于http是基于请求和响应方式协同工作的,因此当服务器端的model(数据)发生变化时,它不会立即更新客户端的view,只有客户端重新请求或刷新页面时才更新.
下图是典型的MVC框架中的MVC一个请求流程。
MVC优点
由于MVC很好的分离了视图层和业务层，所以它具有以下优点
耦合性低
开发速度快
可维护性高
没有控件的概念，对html没有封装，易于理解
和其它平台(java, php)等更加相似。便于人才获取
MVC的缺点
完美的MVC应用场景应该是这样的:
有个Student Model, 关联StudentListView, StudentEditView.
对于StudentListView, Student Model提供Student的集合数据来显示StudentListView
对于StudentEditView, Student Model提供单个Student数据来展示StudentEditView并且响应StudentEditView的保存操作。
但是这只是完美的情况，实际应用中，在ListView上，不单单显示Student的信息，可能还需要这个Student的历史成绩，家庭情况, 老师信息。而这些是Student Model不能提供的。
也许我们可以扩展Student Model, 将Student Model能够提供的信息扩展，包含成绩信息等，这本身也可以。但是，如果Student显示的View，这个需要只是需要额外的成绩信息，另一个View只是需要额外的家庭信息，Student Model是不是有些疲于奔命，你能知道还会有多少个差异化的View的需求? 而且让逻辑端代码这样不断的修改来适应View端，好吗?
由于MVC的设计思想是从Model出发，而没有考虑到View端的复杂性，这样导致的问题是Model难以符合复杂多变的View端变化。
二.MVP模式
MVP有什么好处，为什么要用MVP呢？
优点：
1.解耦
几乎所有的思想都是为了解耦，提高维护性。
解耦在生产中实际效果是，把一个大工程，拆分成多个小工程。每个工程之间相互独立。可单独测试
这样的好处是吧“单线程”变成“多线程”，原来一个人做一年的工作量，现在可以拆成若干个工程，交给多个人一起去做。提高效率，缩短交付时间。
而且每个人只需要专注于自己那一部分，对于大项目，或者工期紧的项目是非常重要的。
2.提高维护性
容易区分边界，一旦出了问题，能立刻定位是哪个模块，哪个个接口除了问题。模型与视图完全分离，我们可以修改视图而不影响模型；
3.容易测试
将业务逻辑从activity，fragment中分离出来。更容易进行单元测试
4.结构清晰
让思路更清晰，不至于自己的代码，过两天再看就成了“别人的代码”了。
缺点：
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了
三.MVVM模式
MVVM里，controller将不再直接和真实的model进行绑定了，而通过ViewModel,viewModel进行持有真实的Model。
关于MVVM的优点：
方便测试
在MVC下，Controller基本是无法测试的，里面混杂了个各种逻辑，而且分散在不同的地方。有了MVVM我们就可以测试里面的viewModel，来验证我们的处理结果对不对（Xcode7的测试已经越来越完善了）。
便于代码的移植
比如iOS里面有iPhone版本和iPad版本，除了交互展示不一样外，业务逻辑的model是一致的。这样，我们就可以以很小的代价去开发另一个app。（以前做公司iPad的时候就深深感觉到，全部在VC里面是多么的痛苦和重新开发一个没有啥区别）。
兼容MVC
MVVM是MVC的一个升级版，目前的MVC也可以很快的转换到MVVM这个模式。VC可以省去一大部分展示逻辑。
缺点：
类会增多
每个VC都附带一个viewModel，类的数量*2
viewModel会越来越庞大
我们把逻辑给了viewModel，那势必Model也会变得很复杂，里面的属性和方法越来越多。可能重写的方法比较多，因为涉及到一些数据的转换以及和controller之间的通信。
调用复杂度增加
由于数据都是从viewModel来，想想突然来了一个新人，一看代码，不知道真实的模型是谁。比如常用tableview的数据源，一般都是一个数组，如果不断的通过viewModel去取，沟通上没有那么直接。况且每封一层，意味着要写很多代码去融合他们的转换。
MVC、MVP、MVVM的适用场景
mvc适用那些小型、个人开发的项目 项目不是特别大 比如简单的java web 项目 用 jsp+servlet+javabean实现
mvp适用那些中小型项目 团队开发 分工明确的
mvvm适用那些大型项目
