面经

MVC/MVP/MVVP区别

所谓的mvp，即是（model-处理业务逻辑（主要是数据读写，或者与后台通信（其实也是读写数据）），view-处理ui控件，presenter-主导器，操作model和view）

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。

在Android开发中，比较流行的开发框架模式采用的是MVC框架模式，采用MVC模式的好处是便于UI界面部分的显示和业务逻辑，数据处理分开。那么Android项目中哪些代码来充当M,V,C角色呢？

1. M层：适合做一些业务逻辑处理，比如数据库存取操作，网络操作，复杂的算法，耗时的任务等都在model层处理。
2. V层：应用层中处理数据显示的部分，XML布局可以视为V层，显示Model层的数据结果。
3. C层：在Android中，Activity处理用户交互问题，因此可以认为Activity是控制器，Activity读取V视图层的数据（eg.读取当前EditText控件的数据），控制用户输入（eg.EditText控件数据的输入），并向Model发送数据请求（eg.发起网络请求等）使用 

MVC，把业务逻辑抽离到 Controller 中，让 View 层专注于显示 UI。

把Controller和View混在一起，有什么问题？

１.难以测试。

　　必须手动点击，使用各种自动化的测试工具。

２.代码难以重用。

　　UI是很难重用，因为要求总是不同。所以，导致重复的代码四处都是，维护麻烦。

MVC/MVP
  View强依赖于Model是MVC的主要问题。由此导致很多控件都是根据业务定制，从Android的角度来看，原本可以由一个通用的layout就能实现的控件，由于要绑定实体模型，现在必须要自定义控件，这导致出现大量不必要的重复代码。因此有必要将View和Model进行解耦，而MVP的主要思想就是解耦View和Model。由此引入MVP就显得很自然。
MVP存在的问题:
尽管已经有了大量的应用，但不可否认该模式的还是存在一些问题，这些问题在携程的使用过程中也得到了体现。比如，上下文丢失问题，生命周期问题，内存泄露问题以及大量的自定义接口，回调链变长等问题。可以归纳为：
1.业务复杂时，可能使得Activity变成更加复杂，比如要实现N个IView，然后写更多个模版方法。
2.业务复杂时，各个角色之间通信会变得很冗长和复杂，回调链过长。
3.Presenter处理业务，让业务变得很分散，不能全局掌握业务，很难去回答某个业务究竟是在哪里处理的。
4.用Presenter替代Controller是一个危险的做法，可能出现内存泄漏，生命周期不同步，上下文丢失等问题。

2.使用MVP的好处

（1）MVP模式会解除View与Model的耦合，有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性，保证系统的整洁

性和灵活性。

（2）MVP模式可以分离显示层与逻辑层，它们之间通过接口进行通信，降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭

配不同的显示界面，因为它们之间并不依赖与具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，

使之具有更广泛的适用性，保证了灵活度。

3.MVP模式的三个角色
（1）Presenter – 交互中间人：Presenter主要作为沟通View与Model的桥梁，它从Model层检索数据后，返回给View层，使得View与Model之间没有耦合，也将业务逻辑从View角色上抽离出来。
（2）View – 用户界面：View通常是指Activity、Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要实现一个逻辑接口，将View上的操作转交给Presenter进行实现，最后，Presenter 调用View逻辑接口将结果返回给View元素。
（3）Model – 数据的存取：Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据，Model就像一个数据仓库。更直白的说，Model是封装了数据库DAO或者网络获取数据的角色，或者两种数据方式获取的集合。

View ：是指显示数据并且和用户交互的层。在安卓中，它们可以是一个Activity，一个Fragment，一个android.view.View或者是一个Dialog。

Model ：是数据源层。比如数据库接口或者远程服务器的api。

Presenter：是从Model中获取数据并提供给View的层，Presenter还负责处理后台任务

• M-Model : 业务逻辑和实体模型(biz/bean)
• V-View : 布局文件(XML)
• C-Controllor : 控制器(Activity)

• M-Model : 业务逻辑和实体模型(biz/bean)
• V-View : 布局文件(XML)和Activity
• P-Presenter : 完成View和Model的交互

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

1. 各部分之间的通信，都是双向的。

2. View 与 Model 不发生联系，都通过 Presenter 传递。

3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

• M-Model : 实体模型(biz/bean)
• V-View : 布局文件(XML)
• VM-ViewModel : binder所在之处，对外暴露出公共属性，View和Model的绑定器

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。

从上图可以看出：MVC的耦合性还是较高的，View可以直接访问Model，导致3者之间构成了回路。所以两者的主要区别是，MVP

中View不能直接访问Model，需要通过Presenter发出请求，View与Model不能直接通信。

在MVP模式里，View只应该有简单的Set/Get的方法，用户用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容

许直接直接访问Model--这就是与MVC很大的不同之处。

2.与MVVM（Model-View-ViewModel）的区别

MVVM与MVP非常相似，唯一区别是View和Model进行双向绑定，两者之间有一方发生变化则会反应到另一方上。MVVM模式有点

像ListView与Adapter、数据集的关系，当数据集发生变化时，调用Adapter的notifyDataSetChanged之后View就直接更新，同时它们

之间又没有耦合，使得ListView变得更加灵活。

http://blog.csdn.net/shareus/article/details/51481308

http://blog.csdn.net/qq_17250009/article/details/51161074