Android开发Android开发经验谈Android技术知识

Android 各类架构横向比对

2018-09-25  本文已影响10人  KunMinX

版权声明:本文为博主原创文章,转载请注明作者和链接。更多请继续关注 KunMinX
https://www.jianshu.com/p/9ef813d5c1af

项目中用到的常见架构

以下,对常见的 MVC、MVP、Clean、AAC 架构做个比较。

首先,用一张图表来展示各架构的类冗余情况:

需求是,写三个页面,ListFragment、DetailFragment、PreviewFragment,每个页面至少用到 3个 Note 业务、3个 User 业务。问:上述架构分别需编写多少类?

架构 涉及类 类总数
MVC Fragment:3个,Model:2个 5个
MVP Fragment:3个,Presenter:3个,Model:3个 9个
Clean Fragment:3个,ViewModel:3个,Usecase:18个,Model:3个 27个
AAC Fragment:3个,ViewModel:3个,Model:3个 9个

MVC 架构的 ... 缺陷 😳

MVP 架构的特点与缺陷 🤔

但 MVP 架构也是有缺陷的。按我的理解,MVP 设计的初衷是, “让天下没有难替换的 View 和 Model” 。该初衷背后所基于的假设是,“上层逻辑稳定,但底层实现更替频繁” 。在这个假设的引导下,使得三者中, 只有 Presenter 具备独立意志和决定权,掌管着 UI 逻辑和业务逻辑,而 View 和 Model 只是外接的工具

然而,这样的假设多数时候并不实际。可视化需求是变化多端的,在牵涉到视觉交互时,必然涉及 UI 逻辑的修改,也就是说,View 和 Presenter 的相互牵连,使得 UI 的改动需要 View 和 Presenter 编写者配合着完成,增加沟通协作成本。

长久以往,二者都难以成长,Presenter 编写者容易被各种非本职工作拖累,View 的编写者不会尝试独立自主,例如通过多态等模式将 UI 封装成可适应性的组件,反正 ... 有 Presenter 来各种 if else 嘛。

Clean 架构的特点与缺陷 🙂

mvp_flow.png

为解决 Presenter 职能边界不明确 的问题,在 Clean 架构中,业务逻辑的职能被转移到领域层,由 Usecase 专职管理。Presenter 则弱化为 ViewModel ,作为代理数据请求,和衔接数据回调的缓冲区。

Clean 架构的特点是 单向依赖、数据驱动编程View -> ViewModel -> Usecase -> Model

View 对 ViewModel 的单向依赖,是通过 databinding 特性实现的。ViewModel 只负责代理数据请求,在 Usecase 处理完业务返回结果数据时,结果数据被赋值给可观察的 databinding 数据,而 View 则依据数据的变化而变化。

但 Clean 架构也是有缺陷的。 粒度太细 。一个 Usecase 只能处理一类请求。View 请求的数据包含几种类型,就至少需要准备几个 Usecase。Usecase 是依据当前 View 对数据的需求量身定制的,因此 Usecase 的复用率极低,项目会因而急剧的增加类和重复代码

AAC 架构的特点 😐

AAC 也是数据驱动编程。只不过它不依赖于 MVVM 特性,而是直接在 View 中写个观察者回调,以接收结果数据并处理 UI 逻辑。

你完全可以将其理解为 B/S 架构:从 Web 前端向 Web 后端发送了数据请求,后端在处理完毕后响应结果数据给前端,前端再依据需求处理 UI 逻辑。等于说, AAC 将业务完全压到了 Model 层

ViaBus 架构的由来及特点 😃

东家目前在用 Clean 架构,为此我决定跳过 AAC,基于对移动端数据交互的理解,编写“消息驱动编程”架构。

由于借助总线来代理数据的请求和响应,因此取名 ViaBus。

viabus_flow.png

不同于以往的架构,ViaBus 明确界定了什么是 UI,什么是业务。

UI 的作用是视觉交互,为此 UI 的职责范围是请求数据和处理 UI 逻辑 。业务的作用是供应数据,因此 业务的职责范围是接收请求、处理数据、返回结果数据

UI 不需要知道数据是怎么来的、通过谁来的,它只需向 bus 发送一个请求,如果有业务注册了该类 “请求处理者”,那么自然有人来处理。业务也无需知道 UI 在拿到数据后会怎么用,它只需向 bus 回传结果,如果有 UI 注册了“观察响应者”,那么自然有人接收,并依据响应码行事。

这样,在静态 bus 的加持下,UI 和业务是完全解耦的,从根本上解决了相互牵连的问题。此外,不同于上述架构的每个 View 都要对应一个 Presenter 或 ViewModel,在 ViaBus 中,一个模块中的 UI 可以共享多个“业务处理者”实例,使 代码的复用率提升到100%

ViaBus 现已在 Github 开源,欢迎 Star & Fork ~

更多访问

Github : KunMinX / android-viabus-architecture
1分钟掌握 ViaBus 架构的使用
在抛弃MVP、Clean架构后,我做了这么一件事

上一篇下一篇

猜你喜欢

热点阅读