Android应用架构 — 从MVC到MVVM

在这套架构模式中，因为Controller不再作为系统与用户的连接，控制器这个名称似乎有些不合理，于是便改名为Presenter（主持人）， 从名称也可以想到，这是一个协调View和Model工作的角色。

MVP架构模式解除了View与Model耦合，避免了业务逻辑出现View中，使在MVC中混乱的数据流/事件流变得清晰起来。 再后来，人们发现Presenter与View之间存在强耦合，这两部分不好独立的进行开发与测试，便运用依赖倒置原则(DIP)提取出接口，让它们相互依赖接口，便有了如今的MVP。

角色划分

• Model：用来保存程序的数据状态，比如数据存储，网络请求等。
• View：GUI组件构成，向用户展示数据，响应用户事件等。
• Presenter：作为沟通View和Model的桥梁，处理来自View层转发的用户请求，从Model层检索数据，通知View层改变界面等。

两种常见的MVP

Passive View

Passive View MVP是最典型的，在该架构模式中，View层是被动的，也就是说，View层本身不会主动改变自己的任何状态，所有状态都交由Presenter间接改变。

Supervising Controller

Supervising Controller MVP与Passive View MVP的不同之处在于前者并没有完全解除View与Model之间的耦合， 而是使用DataBinding这类的框架将View属性与Model中部分数据进行绑定，简单的数据展示直接由View与Model进行同步，而 Presenter只处理复杂的状态同步与模块协调等工作。

解决的问题

1. 规范了传统MVC中混乱的数据流向/事件流向。
2. 将用户事件捕获从Controller(Presenter)中抽离出来，使Controller(Presenter)可以专注于业务逻辑。
3. 解除了View与Model之间的强耦合，使View层能更专注于UI处理。
4. 解除了View与Presenter之间的强耦合，使一个Presenter能够应用于多个View，同时各个模块可以独立开发、独立测试。

存在的问题

• 会引入大量的接口，增加代码结构的复杂性（查看调用逻辑会很麻烦）。
• Presenter层持有View，导致该层不得不感知View的声明周期，带来额外的复杂度。

MVVM架构

起源与发展

从Supervising Controller到Presentation Model

在前文中，我们提到，Supervising Controller MVP使用数据绑定直接将View与Model中部分属性进行绑定，在一定程度上减少了视图与模型之间同步的代码。
然而这种绑定只适用于简单属性-状态的同步，涉及到较为复杂视图状态同步便无能为力了；并且，在业务逻辑较为复杂时，直接将领域模型实体暴露给展示层，可能会导致混合业务逻辑与表示逻辑的问题。

在2004年，Martin Flower提出了Presentation Model，该模式从视图层抽象出一个展示模型， 并命名为Presentation Model，视图则根据这个模型的实体进行渲染。
Presentation Model将视图中的状态和行为放到一个单独的展示模型中，协调领域对象（模型），并为展示层提供接口，从而最大程度的减少在视图层中的逻辑。视图层则将所有状态存储在展示模型中，并保持其状态与展示模型中的状态同步。

MVVM的诞生

在JPresentation Model提出一年后，微软的John Gossman提出了MVVM用于构建WPF应用，而MVVM的思想理念与Presentation Model不谋而合，或者说，前者是后者的一个具体实现。
在MVVM中，Model、View与MVC、MVP中的一致，ViewModel则是Presentation Model中的展示模型。

除了Model、View、ViewModel以外，微软之后还为MVVM引入了一个隐式的Binder层，通过Binder就可以用声明的方式将ViewModel中保存的状态数据与视图的状态相绑定，从而实现展示模型与View自动更新。在Android中，这个Binder就是Google Jetpack中提供的DataBinding。

角色划分

• Model：用来保存程序的数据状态，比如数据存储，网络请求等。
• View：GUI组件构成，向用户展示数据，响应用户事件等。
• ViewModel：保持视图状态相关的数据，提供接口给View层调用以及和仓库层进行通信。
• Binder(可选)：以声明形式隐式的将ViewModel中的状态数据与View进行绑定。

解决的问题

1. 将视图的状态抽离出来，使视图的变化更加纯粹（可以类比纯函数），易于UI测试。
2. 领域模型到视图状态的转换逻辑转移到了ViewModel中，在彻底解除View与Model之间的耦合的同时，对复杂状态的同步也能很好的处理。
3. 声明式的绑定View状态，可以减少大量状态同步代码。

存在的问题

1. ViewState的抽离会产生更多类文件。
2. 对于简单界面简单状态同步会显得很麻烦。
3. Binder隐式绑定可能会导致debug困难。
   结语
   ==
   从GUI应用程序诞生至今，GUI应用程序的架构也在不断的演化进步。从最初的MVC将混乱得代码分成了展示层和领域层，到MVP通过Presenter和依赖倒置实现了这两层的彻底解耦，再到MVVM中抽离View状态让View更加纯粹和使用隐式binder绑定视图以简化状态同步。每一步的演化都是对前辈某一缺陷的补足，但是它们在解决了原有问题的同时往往也会带来新的问题，因此架构里是没有万金油的，我们需要根据实际的场景选择最合适的。
   参考文章
   ====

• GUI 应用程序架构的十年变迁：MVC、MVP、MVVM、Unidirectional、Clean
• 浅谈 MVC、MVP 和 MVVM 架构模式

最后

写到这里也结束了，在文章最后放上一个小小的福利，以下为小编自己在学习过程中整理出的一个学习思路及方向，从事互联网开发，最主要的是要学好技术，而学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯，更加需要准确的学习方向达到有效的学习效果。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

8156601)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！