Google官方MVP架构解析

作者: 芒果味的你呀 | 来源:发表于2018-02-11 21:04 被阅读429次

    实际开发中,一个Activity中有许多的交互事件,这个时候Activity的代码就显得特别的庞大,整个activity显得十分臃肿。Activity既实现视图逻辑,又需要实现部分业务逻辑。

    而我们需要activity是这样的:

    ❤️负责发起处理和用户交互的内容,但又不负责具体的实现;需要显示什么,不显示什么,什么东西显示多少,有个东西可以直接告诉他,Activity不再做复杂的逻辑处理;


    【是时候展现MVP真正的实力了】

    1.MVP,即View,Presenter,Model。

    Model的工作就是完成对数据的操纵,数据的获取、存储、数据状态变化都是model层的任务,如网络请求,持久化数据增删改查等任务。Activity/Fragment(View),只处理视图相关,不做任何逻辑处理。Presenter,作为桥梁,巧妙的将View和Model的具体实现连接了起来。Presenter会根据需要调用model层的数据,处理逻辑并在需要时将回调传入view层。他们各司其职,互相搭配,实现了解耦,完全解放了Activity(或者是Fragment)。这就是MVP 的优势,使代码结构更加清晰。
    关于demo 就看最权威的吧---Google官网关于mvp的GitHub---demo

    2.关于MVC和MVP

    一句话概括MVP与MVC的区别:View能否直接操作Model

    3.动手操作

    【项目目录】

    • 方式一:根据功能进行分模块 google的demo中就是按照这种方式划分的
    • 方式二:也可以按照model,view,presenter这种情况进行划分组织目录,然后再按功能划分

    【base】

    MVP不是没有缺点的,在使用mvp的过程中,会多出很多类,每一个View(Activity或Fragment)都至少需要各自的Presenter和View接口,在加上他们各自的实现,不算model至少也要4个java文件,这样一个稍有点规模的APP,类就会变得异常的多,而每一个类的加载又会消耗资源;因此,相较于MVC,这算是MVP最大的缺点了吧。

    如何使用泛型和抽象优化MVP 的结构就变成了我们用好MVP的关键了。当然,对于这个问题我们可以通过泛型参数、抽象父类的方式,将一些公用的Model及Presenter抽象出来。这应该就是使用MVP架构的精髓了。

    定义基础接口:BaseView和BasePresenter 的接口

    我们可以将基础的View层的操作(除了setPresenter,还可以根据自己的需求,比如网络错误显示页面、加载失败页面、列表为null、正在加载等定义基础方法)放在BaseView里面,对基础的Presenter层的操作(比如获取数据)放在BasePresenter里面。减少后续代码的重复。

    MVP中Presenter和View层是需要交互的,这里通过setPresenter操作,我们也就可以获得Presenter层的实例进行交互了

    public interface BaseView<T> {
        void setPresenter(T presenter);
    }
    
    public interface BasePresenter {
        void loadData();
    }
    

    【模块】

    接下来我们就要根据自己的业务模块编写了。
    比如我们以登录为例:

    第一:我们需要定义一个协议类XXXContract --LoginContract

    一个协议类将View和Presenter管理起来,方便操作。

    public interface LoginContract {
    
        interface View extends BaseView<Presenter> {
            void showLoginSuccessView(String avatar, String nickname);
            void showFailureView();
    
        }
        interface Presenter extends BasePresenter {
            void login();
    
        }
    }
    
    第二:然后编写View实现类 [XXXActivity/XXXFragment] 只与P层交互
    public class LoginFragment extends Fragment implements LoginContract.View{
        private LoginContract.Presenter mPresenter;
        @Override
        public void setPresenter(LoginContract.Presenter presenter) {
            mPresenter = presenter;
        }
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            mPresenter=new LoginPresenter(this);
        }
     @Override
        public void onClick(View v) {
            switch (v.getId()) {
                case R.id.login:
                    mPresenter.login();
                    break;
            }
        }
       @Override
        public void showLoginSuccessView(String avatar, String nickname) {
    //登录成功视图处理
            Glide.with(getActivity()).load(avatar).into(mAvatarView);
            mNicknameView.setText(nickname);
        }
    
    ......
    ......
    }
    
    第三:编写Presenter的实现类,在这里进行model层和view层的交互。这里model层指的就是网络请求对数据的获取,而得到数据后是presenter去决定让view显示什么。它去做逻辑处理。
    public class LoginPresenter implements LoginContract.Presenter {
       private final LoginContract.View mLoginView;
       public LoginPresenter(LoginContract.View loginView) {
            mLoginView = loginView;
            mLoginView.setPresenter(this);
        }
    
        @Override
        public void login() {
          NetManager.login(mLoginView.getContext(), new LoginCallback() {
                @Override
                public void onLoginSuccess(LoginObj response) {
             
                    mLoginView. showLoginSuccessView(response.getAvatar(),response.getNickName());
                }
    
                @Override
                public void onLoginError(Exception obj) {
                    mLoginView.showFailureView();
                }
            });
        }
    }
    
    第四:关于model层,可能有些人该疑问,model在项目中是指哪里呢,model层主要指的就是对数据的处理,比如数据的获取、存储、数据状态变化都是model层的任务,比如Javabean、(你项目封装的底层网络库、数据库),持久化数据增删改查等任务
    要知道model不仅仅只是实体类的集合,同时还包含关于数据的各种处理操作。

    网络请求的发起是在p层,网络请求的回调根据成功与失败等做逻辑处理也是在p层
    但真正去请求获取数据(比如okhttp、或是自己封装的HttpUtil)的复杂任务是在m层处理。

    相关文章

      网友评论

      • Lyhvin:美女好 学习了
      • a0c21083e95e:美女,我来看你了:relaxed:
        Fuuqiu:@Alex老夫子 哪里都有你
        芒果味的你呀:。。。呵呵😑 谢谢了
      • 夺光:其实我总结mvp就是纯粹的mvc,不过为了达到分离的效果要使用接口来实现,代码多还费劲,rx系列mvvm能帮着解决文件太多写的累的问题,但是考虑到组员水平不爱学习的现状,其实我认为对于页面变动较多,mp在一起混杂,v保持纯洁性就可以达到目的了。
        芒果味的你呀:@夺光 最主要的目的还是不要让activity做太多事情就行了。😜
      • BoomHe:蛮好的
        芒果味的你呀:谢谢~简单总结一下~
      • rivc:MVP 见仁见智吧,个人就不太喜欢,可能是实际的项目和公司情况导致的吧:blush:
        芒果味的你呀:@rivc 但代码多了,感觉还是有用的,不然时间长了,耦合太高了

      本文标题:Google官方MVP架构解析

      本文链接:https://www.haomeiwen.com/subject/tnwooxtx.html