Android应用架构 — 从MVC到MVVM

最新推荐文章于 2024-10-04 11:47:50 发布

2401_84121798

最新推荐文章于 2024-10-04 11:47:50 发布

阅读量335

点赞数 3

分类专栏：程序员文章标签： android 架构 mvc

本文链接：https://blog.csdn.net/2401_84121798/article/details/138099922

版权

程序员专栏收录该内容

197 篇文章 1 订阅

订阅专栏

=====

起源与发展

MVC模式最初由Trygve Reenskaug于1979年提出并定义：

Model: Model可以是一个独立的对象，也可以是一系列对象的集合体。
View: View是Model中一些重要数据在视觉上的体现。
Controller: Controller用于连接用户和系统，Controller接收到用户的输入时，会将其转化成合适的事件消息，并将该事件消息传递给一个或多个View。

1979年的MVC

在早期的MVC模式中，因为起初GUI框架羸弱，无法捕获处理用户事件，所以用户的操作事件由Controller捕获并处理，Controller与View之间没有直接联系。它们之间主要靠用户和Model来连接，用户使用Controller发起操作，Controller操作Model更新数据，Model更新完数据，再反映到View上以展示给用户。因此，你可能找到下图这样的结构：

Wiki上的MVC

再后来，随着技术的发展，View层的能力逐渐强大起来，开始能主动监听并处理一些用户事件了，而Controller则负责协助View处理事件，并且揽下了一部分介于View和Model之间的业务逻辑，在这期间MVC演化出了许多不同的分支，这些分支五花八门各不相同，但是无论怎样改变，仍然保持着Model、View、Controller三个组成部分。

五花八门的MVC

在各种分支中，有一个不得不提到的特殊分支。
随着Web开发的兴起，传统的MVC模式遇到了一个麻烦：View在用户的浏览器中显示，而Model存在于服务器中，Model无法主动通知View更新了。
为此Web开发人员改善了MVC的事件流：当用户作出交互请求时，首先将这个交互事件交给对应的Controller，Controller根据情况完成对Model的操作，Model将操作的结果告诉Controller，再由Controller根据结果组装View返回给浏览器。

这样一来，MVC看起来就很像后来的MVP了：

在Web端用的MVC

角色划分

Model: 用来保存程序的数据状态，比如数据存储，网络请求等。
View: GUI组件构成，向用户展示Model中的数据。
Controller: 连接用户和系统，响应交互，传递数据。

解决的问题

MVC最重要的目的并不是规定各个模块应该如何交互和联系，而是将原有的混乱的应用程序划分出合理的层级，把以往一团混乱的代码，按照展示层和领域层分成两个部分。这种分离使得位于领域层中的领域对象可以不需要对展示层有任何了解，因此可以同时为不同的展示层工作，从而初步的实现了领域层与展示层的解耦。

缺点

MVC只是一种指导思想，因而它没有明确的规定各个模块具体应该怎样交互和联系，这使得使用MVC开发的程序其结构总是千奇百怪的，这些千奇百怪的结构也有着各自独特的优势与缺陷。
另外在Android中，XML作为View层功能太羸弱，许多的界面相关的代码不得不写到Activity中，而Activity同时又作为Controller协助View处理用户事件，这使得Activity的职责相当不纯粹。因此在Android中，MVC的Controller和View其实是没有分离的，形成了一种View-Model的结构。

MVP架构

起源与发展

在上文中，我们提到了起源于Web的一种MVC架构变体，这套架构模式除了被广泛应用于Web后端（比如SpringMVC框架），也反哺了客户端架构的演化。

随着GUI框架的不断进化与完善，View层具备了独立的捕获交互事件以及处理交互事件的能力，因此处理交互的逻辑从Controller转移到了View中，这使得Controller直接没有存在的必要了。这种情况也同样体现在Android中：Activity和XML View组成了新View层，而不再需要Controller的角色。

前面提到，Controller在协助View处理用户事件时，还顺便揽下了一部分介于View和Model之间的业务逻辑，比如在View和Model之间传递数据和请求，将Model层返回的数据做一下转换再交给View渲染等等。而Controller的消失则让这部分逻辑不得不去再次回到View或Model中，进而使得View和Model相互耦合起来。

为此，人们便借鉴了Web中的MVC架构，View必须通过Controller向Model发起请求，Controller收到结果再去更新View。这样一来，View和Model就被隔离开了，同时之前那些业务逻辑又有合适的去处了。

长得像MVP的MVC

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

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

使用了DIP的MVP

角色划分

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

两种常见的MVP

Passive View

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

Passive View MVP

Supervising Controller

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

Supervising Controller MVP