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的探讨，如果有发现不对的地方，欢迎批评指正，共同学习提高