开发模式 MVP - 基础框架搭建分析

作者: 如愿以偿丶 | 来源:发表于2019-10-27 13:33 被阅读0次

开发模式 MVP - 基础框架搭建分析
开发模式 MVP - 基础框架搭建分析
开发模式 MVP - 基础框架搭建分析
APP-Base（通用搭建APP基础框架）
基于MVP模式开发的带缓存网络爬虫,采用最流行框架搭建,干货多多
给大佬递茶系列 | 回顾一下GitHub大神的高级操作
Android MVP框架搭建
基于谷歌最新AAC架构，MVVM设计模式的一套快速开发库，整合O
android项目框架搭建demo（RxJava+Retrofi
GitHub标星4.6K+！手写一款基于MVVM模式开发框架，完

1.MVC和MVP的介绍

MVC和MVP在结构上是类似的，都分为三个层

1.1.MVC：

M：Model数据层，一般处理一些网络数据都在这里
V：View界面层，一般代表我们的布局文件，显示数据
C：Controller控制层，一般代表我们的Activity，Fragment等等是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

image.png

优点：
1.理解起来比较容易
缺点：
1.如果是多人开发，相同的业务逻辑，需要每个页面都写一份，代码重复
2.如果某些页面需求变更的时候，需要修改每个页面的代码。不利于后期维护
3.C层处理的业务逻辑太多，需要处理View层的，还需要调用M层获取数据，处理的业务逻辑过于复杂，代码量多，如果出现bug的化，不方便寻找。

1.2.MVP：

M：Model数据层，一般处理访问网络数据都在这里
V：View界面层，与View相关的一些操作都在这里面。View一般代表我们的Activity，Fragment，LinearLayout等等
P：Presenter解耦关联层（关联Model 和 View），可能还要处理一些额外的逻辑操作，数据的处理（比如：数据的筛选等，筛选后给到我们的View去显示）

优点：
1.M层和V层完全分离，只需要通过P，V和P层的桥梁，哪个部分出现问题方便修改。只需要找对应的层级就可以
2.适合多人开发，代码的复用性强
缺点：
1.接口回掉多，类的数量增多

2.,简单基础版本

UserInfoContract

/**
 * Created by ych on 2018/5/27.
 * Description: 用户协议类
 */
public interface UserInfoContract {
    //View层
    interface UserInfoView {
        //正在加载中
        void onloading();

        //加载成功
        void onSuccess(UserResponse response);

        //获取失败
        void onError(String msg);
    }

   //Model层
    interface UserInfoModel {
        Observable<UserResponse> getUser();
    }

    //Presenter层
    interface UserInfoPresenter {
        void getUser();
    }
}

UserInfoModel

/**
 * Created by ych on 2018/5/27.
 * Description:
 */
public class UserInfoModel implements UserInfoContract.UserInfoModel{

    @Override
    public Observable<UserResponse> getUser() {
        return RetrofitHelper.getServiceApi().getUser().compose(RxUtil.<UserResponse>rxSchedulerHelper());
    }
}

UserInfoPresenter

/**
 * Created by ych on 2018/5/27.
 * Description:Presenter层持有   M层和V层引用
 */
public class UserInfoPresenter implements UserInfoContract.UserInfoPresenter{
    private UserInfoContract.UserInfoView mView;
    private UserInfoContract.UserInfoModel mModel;

    public UserInfoPresenter(UserInfoContract.UserInfoView mView) {
        this.mView = mView;
        mModel = new UserInfoModel();
    }

    @Override
    public void getUser() {
        mModel.getUser().subscribe(new Action1<UserResponse>() {
            @Override
            public void call(UserResponse userResponse) {
                //成功
                mView.onSuccess(userResponse);
            }
        }, new Action1<Throwable>() {
            @Override
            public void call(Throwable throwable) {
                //失败
                mView.onError(throwable.getMessage());
            }
        });
    }
}

MVPActivity

public class MVPActivity extends AppCompatActivity implements UserInfoContract.UserInfoView {
    private UserInfoContract.UserInfoPresenter mPresenter;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_mvp);
        initData();
    }

    private void initData() {
        mPresenter = new UserInfoPresenter(this);
        mPresenter.getUser();
    }

    @Override
    public void onloading() {
        //显示Loading
    }

    @Override
    public void onSuccess(UserResponse response) {
        //成功处理
    }

    @Override
    public void onError(String msg) {
        //失败处理
    }
}

这样简单的MVP框架基本就实现了，有好处也有坏处吧，通过上面的事例我们就能看出不好的地方，这个类太多了，但是分层解耦了。这样写完还是会有很多问题存在的。通过上面事例我们在创建Presenter的时候传入的是this，也就是Activity的实例，当我们获取网络数据时，用户按了返回键退出了 activity，当数据返回的时候，如果恰好碰到 GC 回收了一些数据，那么会导致应用崩溃，所以我们必须解绑判断。

修改后：
UserInfoPresenter：

/**
 * Created by ych on 2019/10/27.
 * Description:Presenter层持有   M层和V层引用
 */
public class UserInfoPresenter implements UserInfoContract.UserInfoPresenter{
    private UserInfoContract.UserInfoView mView;
    private UserInfoContract.UserInfoModel mModel;

    public UserInfoPresenter(UserInfoContract.UserInfoView mView) {
        this.mView = mView;
        attachView(mView);
        mModel = new UserInfoModel();
    }

    /**
     * 解绑
     */
    public void attachView(UserInfoContract.UserInfoView userInfoView) {
        this.mView = userInfoView;
    }

    /**
     * 解绑
     */
    public void dettachView() {
        this.mView = null;
    }


    @Override
    public void getUser() {
        mModel.getUser().subscribe(new Action1<UserResponse>() {
            @Override
            public void call(UserResponse userResponse) {
                //成功
                mView.onSuccess(userResponse);
            }
        }, new Action1<Throwable>() {
            @Override
            public void call(Throwable throwable) {
                //失败
                mView.onError(throwable.getMessage());
            }
        });
    }
}

MVPActivity ：

public class MVPActivity extends AppCompatActivity implements UserInfoContract.UserInfoView {
    private UserInfoContract.UserInfoPresenter mPresenter;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_mvp);
        initData();
    }

    private void initData() {
        mPresenter = new UserInfoPresenter(this);
        mPresenter.getUser();
    }

    @Override
    public void onloading() {
        //显示Loading
    }

    @Override
    public void onSuccess(UserResponse response) {
        //成功处理
    }

    @Override
    public void onError(String msg) {
        //失败处理
    }
 
    /**
     * 当页面销毁进行解绑
     */
    @Override
    protected void onDestroy() {
        super.onDestroy();
        mPresenter.dettachView();
    }
}

在 Activity 的 onDestory() 中解绑，这样能解决崩溃的问题，但是新的问题又来了，每次都这么写岂不是很蛋疼？所以肯定要采用泛型和基类统一管理。