一个 App 离不开 Model 和 View 这两个角色, Model 决定了 App 的数据， 而 View 决定怎么向用户展示这些数据，大多框架或组件大体上都是用来处理这两者之间的交互关系的，也要.…。

所以呢一个 App 的架构需要处理两个任务：

第一个任务：就是要把数据存起来 或者从网上把数据拿来

这个任务其实很简单，Model 就是那个干活的。Model 就是数据。比如你登录的时候，你要输用户名和密码，这个用户名和密码就是 Model。还有从服务器回来的 JSON 数据，也是 Model。Model 很懒，它不管你怎么看它，它就是存在那里。有时候存在数据库里有时候存在内存里。反正就是一堆数据，让我们一起...。

架构不好的话，代码就很难看，很难维护。就像一个乱糟糟的房间，你想找个东西都找不到。 造起来。 所以第一个任务，就是要把数据弄明白，弄清楚它是什么存哪，怎么存。

所以 Model 一定要干净。但是很多时候 Model 都不干净，主要原因是它要负责网络请求。其实网络请求不应该在 Model 里应该在 Presenter 或者 ViewModel 里。 我懵了。 但是初学者不懂， 直接把 Retrofit 的回调写在 Model 里这就导致 Model 变得很大，很臃肿。这就是架构不好的表现。

我明白了。 很多新手写代码， Model 写得乱七八糟，什么都往里面塞，连图片路径都塞 Model 里这就不好了。Model 应该只负责数据，也就是数据模型。比如 User 类，里面有 id, name, password。它不应该知道什么叫 Button，什么叫 TextView。如果它知道了那它就是 View 了。

第二个任务：就是要把数据变成你能看见的样子给用户看

推倒重来。 这个任务就是 View 的事。View 就是你看到的界面。登录界面首页，个人中心，这些都是 View。View 很花哨，它负责点击，负责滑动，负责显示文字。但是 View 也很笨。它不懂数据。它不知道什么是 JSON，它不知道什么是 User 对象。它只知道 TextView 要显示什么文字，Button 要怎么变色。

它们之间不能直接打架，得有个中间人。这个中间人就是我们要说的 MVC、MVP、MVVM，官宣。。

View 像个花瓶，好看就行，里面的东西是 Presenter 倒进去的。但是现在的 App 要求越来越高， View 不能只是花瓶了它还要响应点击，还要显示 loading，还要处理错误。所以 View 也很累。这就导致了架构的诞生。架构就是为了解决这两个任务之间的矛盾。一个要存数据，一个要显示数据，挖野菜。。

所以 View 不能直接去操作 Model。如果 View 直接去操作 Model，那 View 就要写很多 Java 代码去解析 JSON。那 View 就变成 Presenter 了。 闹笑话。 所以 View 必须要简单。它只需要把数据传给 Presenter 或者 ViewModel，然后等着接收显示就行。

MVC 是个啥？老掉牙的东西了

我满足了。 MVC 就是 Model-View-Controller。这个名字听起来很厉害，但其实很早以前就有了。在 Android 里MVC 的 Controller 通常是 Activity 或者 Fragment。主要原因是它们既负责 View 的显示，又负责处理点击事件，还要去调用 Model 获取数据。这就导致了 Activity 变成了那个“上帝类”。

这就是 MVC 的缺点。Activity 太重了它承担了太多的责任。它既是 View，又是 Controller。这就导致代码很难复用。你想把登录逻辑放到注册页面用， 别犹豫... 都不行，主要原因是逻辑写在 Activity 里了。所以 MVC 虽然简单，但是不推荐大项目用。除非你的项目特别小，只有几十行代码。

算是吧... 这看起来好像还行。但是如果你要改界面布局， 你要改 `EditText` 的样式，你就得去改 Activity 的布局文件，还得改 Activity 的 Java 代码。主要原因是 Activity 既管 View 又管逻辑。这就耦合了。耦合了就不好了。你想换个界面后来啊发现改了 Activity，别的页面也出问题了。

引起舒适。 上帝类你知道吧？就是什么都要管，什么都要做，再说说把自己累死，代码还写的一塌糊涂。比如你写一个登录页面。Activity 里既有 `EditText`，又有 `Button`。点击 Button 的时候， Activity 获取用户名密码，然后去调用 Model 的网络请求方法。网络请求回来后Activity 解析 JSON，然后把后来啊更新到 `TextView` 上。

MVP 把 Activity 给解放了？

摆烂。 MVP 就是 Model-View-Presenter。Presenter 是 Presenter，它不是 Controller。Presenter 是个中间人，是个服务员。它坐在 View 和 Model 中间。View 是个接口，Activity 实现这个接口。Presenter 知道 View 的接口，View 知道 Presenter 的接口。

这就很麻烦。

代码量翻了好几倍。而且 Presenter 也很容易变得很臃肿。如果业务逻辑很复杂，Presenter 会变得很大，里面全是 if-else 判断。这就跟以前 Activity 变大一样。而且 Activity 和 Presenter 还要互相持有引用。如果内存泄漏了Activity 可能出不去，Presenter 也出不去。

靠谱。 Presenter 像个管家，把 Model 的数据和 View 的显示隔开了。这样代码结构就清晰多了。想改界面就改 View，不影响逻辑。想改逻辑，就改 Presenter，不影响界面。这就是 MVP 的好处。但是 MVP 也有缺点。那就是代码量变多了。你以前写 Activity 只写几十行代码， 现在写 MVP 你得写 Interface，写 Presenter，还要写 Activity 实现 Interface。

然后等着 Presenter 回调就行了。Activity 甚至不需要写 `findViewById` 了 主要原因是 Presenter 直接通过接口调用 Activity 的方法，Activity 只需要传值进去。这样 Activity 就变得非常轻量了。它只负责显示，不负责逻辑。逻辑都在 Presenter 里。

如果不是空的，就去调用 Model 的网络请求。网络请求回来成功， Presenter 解析数据，然后调用 View 的方法，把数据传给 View，让 View 去显示。网络请求回来失败，Presenter 也调用 View 的方法，告诉用户网络出错了。你看，这样 Activity 就干净了。Activity 只需要实现 View 接口，把界面上的控件传给 Presenter，太离谱了。。

它们互相不知道对方的实现类是谁。Model 只跟 Presenter 打交道。这样 Model 就完全不知道 View 的存在。View 也不需要知道 Model 怎么获取数据。Presenter 负责所有的业务逻辑。比如登录的时候，Presenter 拿到用户名密码，先判断是不是空的。如果是空的，就调用 View 的方法，告诉用户输入不能为空。

MVVM 是不是那个魔法？

我明白了。 MVVM 就是 Model-View-ViewModel。ViewModel 是现在的流行趋势。它跟 MVP 的 Presenter 很像，但是又不太一样。ViewModel 是通过 Data Binding 或者 LiveData 来跟 View 交互的。Data Binding 是 Google 提供的一个库，它可以自动把数据绑定到界面上。

如果你不懂这些，你写 MVVM 会很痛苦。而且 Data Binding 虽然方便，但是它也有性能问题。如果数据变化太频繁，界面会卡顿。而且 XML 里面写表达式，有时候会看不懂。所以 MVVM 适合比较新的技术栈。如果你是老手，你可能更喜欢 MVP，主要原因是 MVP 更直观，更容易理解。如果你是新手，MVVM 可能会让你头大。

这样架构就非常灵活了。而且 ViewModel 还有生命周期感知能力。比如屏幕旋转了Activity 销毁了重建了ViewModel 里面的数据不会丢失。主要原因是 ViewModel 是跟宿主组件生命周期绑定在一起的。 我当场石化。 所以 MVVM 是目前 Google 推荐的架构。但是 MVVM 也有门槛。它需要你理解响应式编程，理解观察者模式。

ViewModel 里面的数据变了 LiveData 就会发出通知，View 就会收到通知，然后去更新界面。这样 View 和 ViewModel 就彻底解耦了。ViewModel 不需要知道 View 是什么它只知道它有一个 LiveData。 勇敢一点... View 也不需要知道 ViewModel 是怎么获取数据的，它只需要订阅 LiveData 就行。

你只要在 XML 里面写好 ``， ViewModel 里面的 username 变了界面上的 TextView 就会自动更新。不需要你去调用 `setText` 方法了。这太方便了。ViewModel 也是通过 LiveData 来通知 View 数据变化的。LiveData 是一个响应式数据容器，上手。。

那到底哪个适合登录接口业务？

小丑竟是我自己。 你说学习 MVC、MVP、MVVM，是为了轻松掌握登录接口数据业务。这话说的，架构跟轻松没什么关系。架构是为了让代码更容易维护，更容易 。登录业务其实挺简单的，就是输入账号密码，点击登录，然后调用服务器接口，显示后来啊。但是你要是架构写不好，登录界面也会变得很乱。比如你用 MVC 写登录，Activity 里全是逻辑。

MVC 的 Activity 太重了根本没法维护。

用起来也不算太麻烦。所以我觉得，如果你是为了学习，从 MVP 开始学比较好。主要原因是 MVP 的逻辑比较清晰，Presenter 的角色很明显，就是处理业务逻辑。MVP 适合入门，也适合中小项目。如果你是做大型项目，或者团队里大家都熟悉响应式编程，那用 MVVM 也不错。MVC 现在大体上没人用了除了那种特别老的代码，我当场石化。。

你只需要在 ViewModel 里改变 username 的值，界面就自动变了。这确实很轻松。但是你需要理解 Data Binding 或者 LiveData。对于新手理解这些确实有点难。不过现在有很多现成的库可以用，比如 Jetpack 的 ViewModel, LiveData, Data Binding，可不是吗！。

梳理梳理。 你要改个按钮颜色，还得改 Java 代码。你要加个验证码输入框，还得改布局，还得改逻辑。如果你用 MVP 写登录，Activity 很干净，逻辑都在 Presenter 里。你要改逻辑，就去改 Presenter。你要改界面就去改 XML。这样改起来就方便多了。如果你用 MVVM 写登录，ViewModel 里的数据驱动界面。

登录接口的数据是怎么传的？

登录接口的数据通常都是 POST 请求。参数是用户名和密码。有时候还有验证码。这些数据都是明文传输的，或者加密传输。服务器收到数据后会验证一下。如果用户名密码对了 就返回一个 token，或者返回一个 JSON，里面有个 `code` 字段，`code` 是 0 表示成功，不是 0 表示失败。前端拿到这个 JSON 后就要一个 Toast。整个过程就是这样。数据流是从 View 到 Presenter， 再到 Model，然后再从 Model 回到 Presenter，再说说从 Presenter 回到 View，整一个...。

如果是成功，就要跳转到首页。如果是失败，就要弹出一个吐司，提示用户密码错误。这些逻辑都是在 Presenter 或者 ViewModel 里面写的。View 只负责显示后来啊。比如登录成功， ViewModel 就把 `isLoginSuccess` 变成 true，LiveData 发出通知。View 订阅了 LiveData，收到通知，就跳转页面。

怎么写一个登录的 Presenter？

写 Presenter 其实也不难。先说说定义一个 LoginPresenter 接口，里面定义一个 login 方法。然后定义一个 PresenterImpl 类，实现这个接口。 另起炉灶。 PresenterImpl 里面持有 View 接口的引用，也持有 Model 的引用。在 login 方法里先调用 View 的方法，获取用户名和密码。

然后判断是不是空的。如果是空的，调用 View 的 showError 方法。如果不是空的，调用 Model 的 login 方法。Model 的 login 方法是异步的，它返回一个 Observable 或者 Callback。 交学费了。 PresenterImpl 订阅这个 Observable， 当数据返回的时候，调用 View 的方法，显示后来啊。

public class LoginPresenterImpl implements LoginPresenter {
    private LoginView loginView;
    private LoginModel loginModel;
    public LoginPresenterImpl {
        this.loginView = loginView;
        this.loginModel = new LoginModelImpl;
    }
    @Override
    public void login {
        if  || TextUtils.isEmpty) {
            loginView.showInputError;
            return;
        }
        loginModel.login {
            @Override
            public void onSuccess {
                loginView.showSuccess;
            }
            @Override
            public void onError {
                loginView.showError;
            }
        });
    }
}

你看，这就是一个简单的 Presenter。逻辑很清晰。View 只需要调用 Presenter 的 login 方法，传进去用户名密码就行。剩下的逻辑都是 Presenter 自己做的。Presenter 也不会写死在 Activity 里 你可以把它注入进去，比如用 Dagger2 或者 Retrofit 的 Provider。

主要原因是所有的逻辑都在这里面。网络请求，数据解析，错误处理，界面显示，都在这里面。你只要改 Presenter，就能改所有的逻辑。这就是架构的力量。它把复杂的逻辑拆分成了一个个小的模块，每个模块只做一件事。这样代码就好维护了。

这样 Activity 就更干净了。Activity 只需要实现 LoginView 接口， 然后在 onCreate 里面创建 Presenter，把 View 的引用传给 Presenter。 到时候….. 然后点击登录按钮的时候，调用 Presenter 的 login 方法。就这么简单。写完这个 Presenter，你就掌握了登录接口的数据业务了。

一下 别搞那么复杂

你看啊... 说了这么多，其实就是为了让你明白，架构不是用来炫技的，是用来解决问题的。如果你觉得 MVP 写起来麻烦，那就用 MVP。如果你觉得 MVVM 门槛太高，那就先别用。反正都是 Java 代码，跑起来就行。但是尽量不要用 MVC，特别是那种 Activity 里面全是逻辑的 MVC。那样写出来的代码，就像屎一样。

怎么养家糊口？所以好好学吧。别浪费时间了。

那样你会很痛苦。主要原因是你永远只能写简单的页面。一旦页面逻辑复杂了你就写不下去了。所以学学 MVC、MVP、MVVM 吧。虽然它们听起来很抽象，但是用起来真的很爽。很优雅。用烂的架构写，就会很恶心。所以多花点时间研究研究架构吧。别整天只会写个按钮点击监听，然后获取文本框的值，然后调用接口。

再说说再啰嗦一句，其实写代码跟做人一样。做人要正直，写代码要规范。做人要诚实写代码要注释。做人要讲道理，写代码要逻辑通顺。做人要懂得尊重别人，写代码要懂得尊重阅读代码的人。所以别乱写代码，别写垃圾代码。给别人留条活路，也给自己留条活路。希望这篇文章能帮到你，虽然写得烂了点， 开倒车。 但是全是真心话。如果你觉得有用，就点个赞吧。如果觉得没用，那就当我没写。反正我也不指望你能看懂多少。反正我也没指望你能写出什么好代码。反正我就是个写博客的。写的烂就烂吧，反正也没人看。哎，算了不说了我要去写代码了。再不写代码，明天就要被老板骂了。拜拜了您嘞。