android MVC和MVP探讨

关于这个模式,虽然网上的资料一大堆,但是思索了好久还是决定写一篇自己的心得体会以加深自己的理解,本片以一个耳熟能详的例子来从简单的coding到MVC再到MVP,来说说对这个模式的理解,当然不当之处欢迎批评指正。

什么叫耳熟能详的例子呢?也就是登录功能的例子,因为这玩意儿业务逻辑简单,就是输入户名+密码,然后请求登录操作,很好抽象出来。当然后面还会简单说明用这个例子的真正原因(本篇博文涉及的代码会以android技术实现)。

其实MVC也好,MVP也罢,这两个是框架模式,与我们熟悉的23种设计模式不是一会事儿,设计模式算可以说是解决某一类问题而总结出来的方法,用它来解决项目种某个特定功能的特定方法,可以说有点具体问题具体分析的味道。而框架模式则是一个项目的总纲,如果非说两者的关系,只能表示成使用了MVC/MVP模式的项目可能使用了23种设计模式的几种(或0种)

第一个版本的登录功能

盘古开天之前,一切都是混沌状态,模式这玩意还没有诞生出来(哦,差点忘了那时候还没电脑),古猿们写登录模块的代码可能如下:

public class LoginActivity extends Activity {
    EditText userNameEdit;
    EditText passwordEdit;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.login_layout);

        userNameEdit = (EditText) findViewById(R.id.userName);
        passwordEdit = (EditText) findViewById(R.id.password);
        //登录点击
        findViewById(R.id.login).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
              //获取用户名和密码
             String userName = userNameEdit.getText().toString();
             String password = passwordEdit.getText().toString();
             //执行登录请求
             doLogin(userName, password);

            }
        });
    }

 private void doLogin(String userName, String password){
        //组织参数
        Map<String, String> params = new HashMap<>();
        params.put("name", userName);
        params.put("password", password);

        //创建HttpUrlConnection对象
        URL url = new URL("http://www.xx.xxx");
        HttpURLConnection connection = (HttpURLConnection) url.openConnection();
        connection.setUseCaches(false);
        connection.setDoInput(true);
        connection.setRequestMethod("POST");

        //为connection 创建post请求参数
        StringBuilder encodedParams = new StringBuilder();
        for (Map.Entry<String, String> entry : params.entrySet()) {
            encodedParams.append(URLEncoder.encode(entry.getKey(), "UTF-8"));
            encodedParams.append('=');
            encodedParams.append(URLEncoder.encode(entry.getValue(), "UTF-8"));
            encodedParams.append('&');
        }

        connection.setDoOutput(true);
        connection.addRequestProperty("Content-Type",
                "application/x-www-form-urlencoded; charset=UTF-8");
        DataOutputStream out = new DataOutputStream(connection.getOutputStream());
        out.write(encodedParams.toString().getBytes("UTF-8"));
        out.close();

          int responseCode = connection.getResponseCode();
        if (responseCode == 200) {
            //显示登录成功页面
            setContentView(R.layout.login_success);
        }else{
           //显示登录失败页面
            setContentView(R.layout.login_failer);
        }

    }

}

这种代码跑起来当然没问题,但是当前登录页面或者说Activity责任太多了:
1、负责显示UI
2、负责处理登录请求:创建HttpURLConnection对象,然后发起登录请求
3、其他责任,比如Activity的生命周期等

就相当于一个饭店里的厨师既负责做饭,又负责买菜,还负责到客户面前问食客点菜,甚至还准备让厨师负责送外卖,这么多活儿(责任)堆积起来,就一个结果:厨师享年在当日三更!!!(累死了)

你可能会说就这么简单的登录逻辑,想这么多干嘛!但是登录逻辑这是一个简单的例子,比如业务复杂的话,业务逻辑代码全部都写在一个java类中,Activity的代码量可以说是轻松上千行,到时候维护都是个问题;再比如就拿这个简单的登录功能来说,如果我想把登录界面不是用Activity来展示,用Fragment、H5、Dialog等等手段来展示登录页面,那么上述的doLogin方法如果不做组织的话,就得ctr+c/ctr+v复制到H5,Fragment,Dialog中;如果登录逻辑有改动的话,那么就得修改若干处。遇到更复杂的业务,维护起来何其蛋疼。

写到此处想起初次接触Servlet的时候(不了解Servlet的童鞋在此处可以简单的将之理解为java代码里面拼写HTML代码),一个简单的登录功能在一个Servlet里面既要处理登录逻辑,又要动态的拼接Html代码生成web页面,代码的可维护性和可读性很差劲儿,造成这样的原因还是因为Servlet的责任太多:
1、要处理登录逻辑
2、还要负责动态拼接html代码
如果你想要修改登录页面的展示样式,在修改Servlet代码里面的html代码的时候手一抖可能就会出现错误,增加来调试成本。

后来继续学习JSP技术(JSP可以简单的理解为在静态的HTML中写java代码),也写了个登录功能。jsp的好处之一就是写html代码比较方便,不像servlet那样全部是字符串拼接html代码,但是同样的在jsp中写大量的业务逻辑代码仍然不可取。

总之上面三个版本(android/servlet/jsp)的登录功能的通病就是界面展示和有业务逻辑混杂在一块,让界面展示和业务逻辑分开让他们各司其职,UI工作的只负责渲染UI,业务方面都交给专门负责业务处理的工作。


第二个版本的登录功能

所以如果看过《重构,改善代码既有设计》这本书的话,你可能想到会对上述代码做一下重构,重构后的代码如下:

public class Login2Activity extends Activity {
    EditText userNameEdit;
    EditText passwordEdit;
    LoginService mLoginService;

    protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        setContentView(R.layout.login_layout);

        userNameEdit = (EditText) findViewById(R.id.userName);
        passwordEdit = (EditText) findViewById(R.id.password);

        mLoginService = new LoginService(new ILoginCallback() {
            @Override
            public void loginSuccess() {
                setContentView(R.layout.login_success);
            }

            @Override
            public void loginFailer() {
                setContentView(R.layout.login_failer);
            }
        });

        //登录点击
        findViewById(R.id.login).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                String userName = userNameEdit.getText().toString();
                String password = passwordEdit.getText().toString();
                //执行登录
                mLoginService.doLogin(userName, password);
            }
        });
    }
}

对比上下代码可以发现做了如下改动:
1、原来的登录逻辑转移到了LoginService对象中
2、点击登陆的时候调用了LoginService的login方法进行登陆
3、因为登录的结果要回调给Activity,所以有设计了ILoginCallback接口,在初始化LoginService的时候对其进行初始化:

public interface ILoginCallback {
    void loginSuccess();
    void loginFailer();
}

在登录请求返回后,调用callback的loginSuccess/loginFailer来向用户展示不同的结果。

这样的话登录原来的登录逻辑就从LoginActivity中转移到了LoginService中,LoginActivity收到用户登录请求的时候,调用LoginServide的login方法即可,重构后的LoginService代码如下:

这里写图片描述

也就是说第二个版本的功能没做多少改动,主要是将用户界面和登录逻辑操作拆分开来,这样UI和登录逻辑的各自的变动都不会受到影响,各司其职,各行其是,且登录逻辑还具有很好的复用性。两个版本的登录功能可以用下图来做个直观的对比:
这里写图片描述


第三个版本的登录功能
稍微分析上面的代码,就会发现不妥之处:比如LoginService可扩展性不强,现在用的HttpUrlConnection来作为网络请求的工具,如果后期要求改网络框架呢,那么我们不得不修改LoginService的代码,如果多次替换框架的话不得不多次修改;且如果要换回原来代码的话,还得查找git的commit纪录来找回原来的实现。简直是what the fuck, 这也可以说是违背了对扩展开放,对修改关闭的原则。

所以为了防止上面情况的放生,以及对登录行为作约束,提供了登录接口:

//登录接口,处理登录业务逻辑
public interface ILogin {
    void login(String userName,
               String password,
               ILoginCallback loginCallback);
}

然后我们在重构LoginService的实现,新的LoginService2如下:

//实现了ILogin接口
public class LoginService2 implements ILogin {

    @Override
    public void login(String userName, String password, ILoginCallback loginCallback) {

        //省略部分代码

        int responseCode = connection.getResponseCode();
        if (responseCode == 200) {
            if (loginCallback != null) {
                loginCallback.loginSuccess();
            }
        } else {
            if (loginCallback != null) {
                loginCallback.loginFailer();
            }
        }
    }
}

那么新的登录Activity的逻辑则相应的修改如下:

public class Login3Activity extends Activity {
    //省略部分代码
    ILogin mLogin;

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.login_layout);

        //省略部分代码

        mLogin = new LoginService2();

        //登录点击
        findViewById(R.id.login).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
              //省略部分代码
              mLogin.login(userName, password, new ILoginCallback() {
                    @Override
                    public void loginSuccess() {
                        setContentView(R.layout.login_success);
                    }

                    @Override
                    public void loginFailer() {
                        setContentView(R.layout.login_failer);
                    }
                });
            }
        });
    }
}

为了后面的讲述方便,可以将上面的代码改成如下样式,让Activity 实现ILoginCallback:
这里写图片描述
此时我们在想替换网络请求框架的话,没有必要修改原来的实现;在保留原来实现的基础上,在提供一个类,让该类实现ILogin接口,login方法的具体逻辑用新的网络框架来实现即可。

所以新版本用图来跟上面两个版本的做比较就如下所示了:
这里写图片描述

这是MVC吗?

为什么会有这个问题呢,这是我翻阅些许资料后产生的疑惑,就是这个疑惑差点让我放弃了写这篇文章。因为我发现我没法从代码上来说服自己这就是MVC,有点心误导别人。于是本篇博客的写作停滞了几天,而后才算悟出我犯了一种什么样的错误,MVC本身就是一种指导思想,而不是代码编写的具体提现,其目的是实现页面和业务逻辑以及数据的解耦,如果你有更好的方式来实现他们的解耦,是否是MVC或者是否非要在自己的代码中强硬的指出谁是M,谁是C有什么必要么。而我确钻到代码实现的牛角尖严格将自己的代码往MVC的定义上靠拢,以试图来解释这就是MVC。

而且在是实现上看如果单纯的把xml当作View的话,但是其能做的工作是少之又少,大部分的事件处理代码还都是交给Activity中,而不是像html/jsp那样点击某个input按钮事件处理代码就是写在html/jsp,然后发送到具体的controller去。这就感觉Activity即像Ctroller又像是View。在这里如果把Activity看作View的话,那么这句话就不难理解(摘自本文):

Most of the modern Android applications just use View-Model architecture,everything is connected with Activity.

就是说上面的看起来像是简单的MV或者VM模式

上面的论断有点拗口,如果有理解不当的地方欢迎批评指正,博主写博客的初衷出了分享自己的心得体会之外,还有就是“让别人指出自己的错误之处,然后改正从中加深理解”

啰嗦了这么多,回归正题!!!

单从整体视觉上看,就一个Activity和ILogin对象(因为View的宿主是Activity,在这里姑且看成一个整体),也就是说我们此时把Activity当成一个View来看待。但是呢如果真要区别分析的话,整个登录功能确实有三种对象:
1、一个是Activity对象,负责诸如证明周期的管理工作
2、一个登录页面对象(LoginView)
3、一个实现登录功能的ILogin接口

根据上面三条,那么代码的组织可以换成如下方式实现:
首先看下Activity:

public class Login4Activity extends Activity implements ILoginCallback {
    //登录页面
    LoginView loginView;

    //登录业务逻辑接口
    ILogin loginModel;

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //初始化登录页面
        loginView = new LoginView(this);

        setContentView(loginView.getLoginView());

        //初始化登录业务逻辑对象
        loginModel = new LoginService2();

        loginView.setLoginListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                //点击登录按钮,实现登录
                loginModel.login(loginView.getUserName(), loginView.getPassword(), Login5Activity.this);
            }
        });

    }

    //登录成功回调
    public void loginSuccess() {
        setContentView(R.layout.login_success);
    }

    //登录失败回调
    public void loginFailer() {
        setContentView(R.layout.login_failer);
    }
}

Activity持有了LoinView和ILogin这个负责业务逻辑的对象,在这次我故意把业务逻辑对象命名为loginModel.

所以看看LoginView的实现就是如下所示了:

public class LoginView {
    private ViewGroup loginView;

    private EditText userNameEdit;
    private EditText passwordEdit;
    private View loginBtn;

    public LoginView(Context context) {
        //初始化登录页面
        loginView = (ViewGroup) LayoutInflater.from(context).inflate(R.layout.login_layout, null);

        userNameEdit = (EditText) loginView.findViewById(R.id.userName);
        passwordEdit = (EditText) loginView.findViewById(R.id.password);
        loginBtn = loginView.findViewById(R.id.login);
    }

    //设置登录点击
    public void setLoginListener(View.OnClickListener loginListener) {
        loginBtn.setOnClickListener(loginListener);
    }

    //获取用户名
    public String getUserName() {
        return userNameEdit.getText().toString();
    }

    //获取用户密码
    public String getPassword() {
        return passwordEdit.getText().toString();
    }

    public View getLoginView() {
        return loginView;
    }

}

貌似有点MVC的味道了!但是这是纯粹的MVC吗?感觉MVC在android种不论怎么写都写不去那种写web时MVC味道来,总而言之可能就是Activity这个干了太多View的事儿吧(毕竟在android种View的宿主可以说就是Activity,不像网页那样,网页的宿主可以说是浏览器,跟具体的Controller没啥关联)

鉴于Activity和View千丝万缕的联系,还是将Activity当作View层来处理吧,本文后面的View如果没有特殊说明,指的就是Activity了


上面的例子种因为我们定义了ILogin接口,所以可以对登录的业务逻辑做很好的扩展。就像上面的图示:分别扩展了UrlConnectionLogin,VolleyLogin,OkhttpLogin等等等,从上面的代码看,我们将一个Activity 作为登录回调接口ILoginCallback的实现类,为了很好的说明MVP,现在将ILoginCallback有意的重命名为ILoginView:

public interface ILoginView {
    void loginSuccess();

    void loginFailer();
}

原来对应的ILogin接口修改为ILoginModel:

public interface ILoginModel {
    //将ILoginView替换原来的ILoginCallback
    void login(String userName,
               String password,
               ILoginView loginView
               );
}

那么对应的Login4Activity就该为如下所示了:

public class Login5Activity extends Activity implements ILoginView {
    //登录页面
    LoginView loginView;

    //登录业务逻辑接口
    ILoginModel loginModel;
    //省略部分代码

    public void loginSuccess() {
        setContentView(R.layout.login_success);
    }

    public void loginFailer() {
        setContentView(R.layout.login_failer);
    }
}

LoginService修改如下:

//实现了ILoginModel
public class LoginService3 implements ILoginModel {

    /**
    *第三个参数由原来的ILoginCallback改成ILoginView
    **/
    @Override
    public void login(String userName, String password, ILoginView loginView) {
             //省略部分代码
            int responseCode = connection.getResponseCode();
            if (responseCode == 200) {
                if (loginView != null) {
                    loginView.loginSuccess();
                }
            } else {
                if (loginView != null) {
                    loginView.loginFailer();
                }
            }
    }
}

就这样,因为ILoginView接口的存在,我们很容易更改我们的登录页面的展现方式,比如我们将登录界面用Dialog或者Fragment来想用户展示,那么我们直接让Dialog或者Fragment实现ILoginView 接口,并将其丢给ILoginModel即可。这样UI 的变化,并不能影响业务逻辑;相反的业务逻辑的修改也不会影响到UI。

那么用第四幅图来跟前面三个图做一个对比,就很明显了:

这里写图片描述


MVP粉墨登场

但是这么写会有一个问题,比如从View这个层面来说,View和Model绑定耦合在了一起;比如有若干个登录页面(扯淡,实际项目中哪有这么多登录页面,just case),那么若干个登录里面都得持有ILoginModel的实现类,如ILoginModel改变的话,那么就需要把若干个登录页面于ILoginModel有关的代码全部都得改,想想就疯了。

关键还是怎么解决View和Model的解耦问题,所以MVP的P角色闪亮登场。P作为中间人的角色,持有ILoginView和ILgoinModel,这样ILoginModel的改变不会影响ILonView
为了用MVP实现这个登录功能,现将原有的ILoginView接口新增两个方法:


public interface ILoginView {
    void loginSuccess();

    void loginFailer();

    //新增方法
    String getUserName();

    //新增方法
    String getPassword();
}

所以LoginPresenter这个P角色的代码就可以简单写成:


public class LoginPresenter {
    //登录业务逻辑接口
    private ILoginModel loginModel;
    //登录界面
    private ILoginView loginView;

    public LoginPresenter(ILoginView loginView) {
        //如果ILoginModel需要修改的话,修改此处即可
        this.loginModel = new VolleyLoginModel();
        this.loginView = loginView;
    }

    //实现登录方法
    public void login(){
        loginModel.login(loginView.getUserName(),loginView.getPassword(),loginView);
    }
}

可以看出LoginPresenter很简单,就是持有一个ILoginView和ILoginModel的引用,且ILoginView是外部初始化传过来的,ILoginModel是内部自己初始化。这样的话即使ILoginModel的实现类有改动,比如有VolleyLoginModel改为OkhttpLoginModel,修改LoginPersenter里面的ILoginModel代码即可,而不需要将每个ILoginView中关于ILoginModel的代码都改一遍,即将

 this.loginModel = new VolleyLoginModel();

改成:

 this.loginModel = new OkhttpModel();

当然如果抽象的好的话,login 方法应该也是一个接口方法比较好。
同样的LoginActivity,将修改为如下实现:

public class Login6Activity extends Activity implements ILoginView {
    //登录页面
    LoginView loginView;

    //登录Persenter
    LoginPresenter loginPresenter;

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //初始化登录页面
        loginView = new LoginView(this);
        setContentView(loginView.getLoginView());

        //初始化LoginPresnter
        loginPresenter = new LoginPresenter(this);

        loginView.setLoginListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                //调用登录方法:见上面实现
                loginPresenter.login();
            }
        });

    }

    public void loginSuccess() {
        setContentView(R.layout.login_success);
    }

    public void loginFailer() {
        setContentView(R.layout.login_failer);
    }

    @Override
    public String getUserName() {
        return loginView.getUserName();
    }

    @Override
    public String getPassword() {
        return loginView.getPassword();
    }
}

所以简单的MVP就实现了,那么用第五副图片做对比的话,则如下所示:
这里写图片描述

最后再来个来个经典的MVP图片总结上图(图片来源百度百科):这里写图片描述

其实说白了,MVP就是解耦问题,解耦的问题首先是要抽象,比如IView,IModel等接口的设计。但是呢,抽象的前提是你要对业务或者需求有所了解,为什么博主会拿登录作为本篇的demo,因为业务简单好抽象,在实际开发中可能你做了抽象开始还很好,但是随着需求的不断变化会让你不段频繁的修改接口,比如你修改IView接口相关的实现类都需要改;同样的你修改IModel接口,那么相应的Model也需要改;频繁的改动可能会出现各种问题;所以MVP的利弊博主水平不够,还没发对此作出评论。不做对于简单业务来使用的话,MVP确实使得代码结构很清晰了 。

以上就是博主对于MVP的探讨,如果有发现不对的地方,欢迎批评指正,共同学习提高

©️2020 CSDN 皮肤主题: 游动-白 设计师:上身试试 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值