MPV 是从经典的MVC模式演变过来的,其基本思路都是相通的。
MVP是模型(Model)、视图(View)、控制者(Presenter)的缩写,分别代表项目中3个不同的模块。
模型(Model):负责处理数据的加载或者存储,比如从网络或本地数据库获取数据等;
视图(View):负责界面数据的展示,与用户进行交互;
控制者(Presenter):相当于协调者,是模型与视图之间的桥梁,将模型与视图分离开来。
在Andorid项目中,我们习惯将Activity作为MVC中的控制者来达到Model模型和View视图分离,但是在MVP框架模式中,通常将Activity作为View视图层,因为在MVC框架模式中Activity和View视图显示关联紧密,Activity中包含大量的View视图显示代码,如果哪天老板说需要修改View视图显示,这时候你是不是感觉需要修改Activity中的大量代码?这么一来会将Activity中控制逻辑破坏,也导致Activity中承担太多的职责。根据单一职责原则,Activity主要起到用户交互作用,也就是接收用户输入,显示请求结果。因此可以通过MVP框架模式来减轻Activity的职责。
如下图所示,View与Model并不直接交互,而是使用Presenter作为View与Model之间的桥梁。其中Presenter中同时持有Viwe层以及Model层的Interface的引用,而View层持有Presenter层Interface的引用。当View层某个界面需要展示某些数据的时候,首先会调用Presenter层的某个接口,然后Presenter层会调用Model层请求数据,当Model层数据加载成功之后会调用Presenter层的回调方法通知Presenter层数据加载完毕,最后Presenter层再调用View层的接口将加载后的数据展示给用户。这就是MVP模式的整个核心过程。
这样分层的好处就是大大减少了Model与View层之间的耦合度。一方面可以使得View层和Model层单独开发与测试,互不依赖。另一方面Model层可以封装复用,可以极大的减少代码量。当然,MVP还有其他的一些优点,这里不再赘述。下面看下MVP模式在具体项目中的使用。
我举一个获取天气的例子来说明,这样大家会很容易看懂
Model模型
-
-
-
- public interface WeatherModel {
- void loadWeather(String cityNO, OnWeatherListener listener);
- }
- .........
-
-
-
- public class WeatherModelImpl implements WeatherModel {
- @Override
- public void loadWeather(String cityNO, final OnWeatherListener listener) {
-
- VolleyRequest.newInstance().newGsonRequest("http://www.weather.com.cn/data/sk/" + cityNO + ".html",
- Weather.class, new Response.Listener<weather>() {
- @Override
- public void onResponse(Weather weather) {
- if (weather != null) {
- listener.onSuccess(weather);
- } else {
- listener.onError();
- }
- }
- }, new Response.ErrorListener() {
- @Override
- public void onErrorResponse(VolleyError error) {
- listener.onError();
- }
- });
- }
- }
和MVC一样,Model的代码不变,只是用与处理网络请求,请求成功后接口回调将Model模型处理的数据返回给Presenter控制者。
Presenter控制器
-
-
-
- public interface WeatherPresenter {
-
-
-
- void getWeather(String cityNO);
-
- }
- ..........
-
-
-
-
- public interface OnWeatherListener {
-
-
-
-
-
- void onSuccess(Weather weather);
-
-
-
- void onError();
-
- }
- .........
-
-
-
-
- public class WeatherPresenterImpl implements WeatherPresenter, OnWeatherListener {
-
- private WeatherView weatherView;
- private WeatherModel weatherModel;
-
- public WeatherPresenterImpl(WeatherView weatherView) {
- this.weatherView = weatherView;
- weatherModel = new WeatherModelImpl();
- }
-
- @Override
- public void getWeather(String cityNO) {
- weatherView.showLoading();
- weatherModel.loadWeather(cityNO, this);
- }
-
- @Override
- public void onSuccess(Weather weather) {
- weatherView.hideLoading();
- weatherView.setWeatherInfo(weather);
- }
-
- @Override
- public void onError() {
- weatherView.hideLoading();
- weatherView.showError();
- }
- }
从代码中我们可以看到Presenter控制器同时持有 WeatherModel和WeatherView对象且实现了OnWeatherListener接口取回Model模型数据,因此,WeatherPresenterImpl向WeatherModel发送数据请求,然后通过OnWeatherListener接口实现获取请求结果,在将结果通过接口WeatherView把数据显示到Activity担当的View视图中。从而达到彻底将Model和View完全分离,试想在这种情况下,如果你需要修改Model是完全不会影响View视图代码的修改的,同理,修改View视图层的时候,也完全无需修改Model层。相当于Model和View互相不知道对方的存在,都是通过中间控制器Presenter来传达通信。
View视图
先定义一个View视图显示的接口WeatherView
新闻列表模块主要是展示从网络获取的新闻列表信息,View层的接口大概需要如下方法:
(1)加载数据的过程中需要提示“正在加载”的反馈信息给用户
(2)加载成功后,将加载得到的数据填充到RecyclerView展示给用户
(3)加载成功后,需要将“正在加载”反馈信息取消掉
(4)若加载数据失败,如无网络连接,则需要给用户提示信息
根据上面描述,我们将View层的接口定义如下,分别对应上面四个方法:
- public interface WeatherView {
- void showLoading();
-
- void hideLoading();
-
- void showError();
-
- void setWeatherInfo(Weather weather);
- }
然后实现Activity实现WeatherView接口
-
-
-
- public class WeatherActivity extends BaseActivity implements WeatherView, View.OnClickListener {
- ..........................
- private WeatherPresenter weatherPresenter;
-
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- init();
-
- }
-
- private void init() {
- <span style="white-space:pre"> </span>....................
-
- findView(R.id.btn_go).setOnClickListener(this);
-
- weatherPresenter = new WeatherPresenterImpl(this);
- loadingDialog = new ProgressDialog(this);
- loadingDialog.setTitle("加载天气中...");
- }
-
- @Override
- public void onClick(View v) {
- switch (v.getId()) {
- case R.id.btn_go:
- weatherPresenter.getWeather(cityNOInput.getText().toString().trim());
- break;
- }
- }
-
-
- @Override
- public void showLoading() {
- loadingDialog.show();
- }
-
- @Override
- public void hideLoading() {
- loadingDialog.dismiss();
- }
-
- @Override
- public void showError() {
-
- Toast.makeText(getApplicationContext(), "error", Toast.LENGTH_SHORT).show();
- }
-
- @Override
- public void setWeatherInfo(Weather weather) {
- WeatherInfo info = weather.getWeatherinfo();
-
- .....................
- }
-
- }
总结:
MVP框架模式完全将Model模型和View视图分离,从而使得代码的耦合低,利用MVP框架写项目达到解耦作用。 MVP和MVC最大的区别是:MVC中的V和C关系比较紧密,耦合度太高,从C中访问M获取数据一定程度上也可以看成从V中访问M。而MVP中M和V完全分离,互相不知道对方的存在,Presenter通过接口通信方式将V和M通信。 在Android中MVP框架 Activity担当View视图层,MVC框架模式Activity担当控制器。从MVC到MVP的一个转变,就是减少了Activity的职责,减轻了它的负担,简化了Activity中的代码和一些操作,将逻辑代码提取到了Presenter中进行处理,降低了其耦合度。
虽然MVP可以达到很好的解耦效果,可是在开发的过程中需要多写一层(Presenter)的代码,代码量会扩大,而且业务逻辑对不太熟悉的开发者来说还是略显复杂,因此建议如果开发相对较小的项目,而且项目不需要频繁的修改可以选用MVC,如果开发比较大的项目,而且需要后期不断地维护修改的话建议使用MVP框架模式开发。
mvp优点:
1、模型与视图完全分离,我们可以修改视图而不影响模型;
2、可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部;
3、我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
4、如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。