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