1.MVC
View：对应于xml布局文件
Model：实体模型
Controllor：对应于Activity业务逻辑，数据处理和UI处理
xml的view功能太过于弱化，导致actvity里面即处理业务逻辑，又处理view。这样activity的类的代码比较长。
2.MVP
View:对应于Activity和xml，负责View的绘制以及与用户交互
Model:依然是实体模型
Presenter: 负责完成View于Model间的交互和业务逻辑
用得比较多，把视图操作和业务逻辑分开来。复杂的业务同时会导致presenter层太大，代码臃肿的问题。通过UI事件的触发对数据进行处理。activity需要编写大量的事件。通过事件调用presenter的业务处理方法。UI改变后牵扯的逻辑耦合度太高。View和Presenter只是互相持有引用并互相做回调,代码不美观。
3.MVVM
View:对应于Activity和xml，负责View的绘制以及与用户交互
Model:实体模型
ViewModel:负责完成View于Model间的交互,负责业务逻辑
数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)
缺点:
1.数据绑定使得bug很难被调试
2.如果项目过大，数据绑定需要更大的内存
参考网址
http://www.jianshu.com/p/2fc41a310f79