一、 传统MVC

View：对应的是各种Layout布局文件

Controller：对应的是Activity，而Activity中却又具有操作UI的功能，我们在实际的项目中也会有很多UI操作在这一层，也做了很多View中应该做的事情,当然Controller中也包含Controller应该做的事情，比如各种事件的派发回调，而且在一层中我们会根据事件再去调用Model层操作数据**

model：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。

二、 传统MVP

MVP中把Layout布局和Activity作为View层，增加了Presenter，Presenter层与Model层进行业务的交互，完成后再与View层交互（也就是Activity）进行回调来刷新UI。

优点：所有业务逻辑的工作都交给了Presenter中进行，使得View层与Model层的耦合度降低，Activity中的工作也进行了简化。

缺点：在实际项目中，随着逻辑的复杂度越来越大，Activity臃肿的缺点仍然体现出来了，因为Activity中还是充满了大量与View层无关的代码，比如各种事件的处理派发，就如MVC中的那样View层和Controller代码耦合在一起无法自拔。（最后一句不是很明白特制什么）

三、 进化版MVP

View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)

Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)

Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。

*View interface:需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试

笔者个人分析：所有的互都发生在一个地方——Presenter内部，处理复杂逻辑的Presenter是通过interface与View(Activity)进行交互的，也就是说Presenter不直接和View（Acitivity）接触，如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。通过Interface似的功能单元化了。通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。