Square对iOS App架构的新尝试---Ziggurat

最新推荐文章于 2024-10-22 09:37:35 发布

翻译最新推荐文章于 2024-10-22 09:37:35 发布 · 590 阅读

iOS高级开发专栏收录该内容

25 篇文章

订阅专栏

Ziggurat是一种针对iOS应用的架构模式，旨在通过单向数据流和分层设计解决传统MVC架构中的问题，如ViewController过于臃肿、调试困难等。此模式引入了服务器、渲染器等组件，简化了业务逻辑，提高了可测试性。

今年六月，我做了一场关于避免臃肿的ViewController的演讲，用Swift讲解了一种采用“单向数据流”的架构模式。当时并没有发布相关的博客，甚至没有给这个架构起个名字。现在两者都有了。首先介绍一下Ziggurat：它是一种通过不可变的视图模型和单向数据流来实现的分层的、易测试的架构模式。

这个架构的名字Ziggurat是根据阶梯状的金字塔得来的。像金字塔的阶梯一样，数据以数据流的形式单向地沿着App的层级传递，并逐层缩小。单向不可变的数据流可以减少认知负载，同时使类也变得更加瘦小。和Ziggurat相比，典型的MVC架构显得缺少了一些指导性，对数据和状态的操作可能散落各处，包括ViewController。

Ziggurat结合了大量讨论和文章中的概念，相关内容列在了下文中更多参考部分。（剧透一下：这个架构的灵感来源于之前Facebook关于React Native的讨论，并且它和Flux也很相似）。这里提及的这些架构模式与MVC相比都是一种更好的选择。

下面将具体介绍Ziggurat：阐述它的背景，权衡分析优缺点，定义它的组件，并通过一个例子来介绍它的用法。

MVC带来的问题

Ziggurat是MVC的替代选择。MVC只是简单地将每部分的责任分离开，但并没有将每个角色和责任分离的很清晰适当。下面是MVC带来的常见问题：

臃肿的ViewController

ViewController负责处理数据、管理I/O、请求API、包含了Model类，以及其他超出它的范围的任务：管理视图及UI事件。

共用数据造成很难调试的Bug

谁应该处理数据？什么时候处理数据？如果不经过精心设计，那么答案将是谁都可以处理、什么时候都能处理。没有搞清这些会造成一些列的连锁效应。

太多的责任导致难以测试

没有采用单一责任原则时会使界限变得不明确且不易发现。

在实践中，由MVC缺少隔离导致的App没有一种清晰地设计模式使得测试和调试bug变得非常困难。对一份代码，不应该让工程师们通过将一个App的设计模式和数据模型做逆向工程的方式来提高工作效率。

描述组件和单向数据流

这个例子使用了这个架构模式，并且所有的组件都有说明文档
上面例子的说明文档提供text格式文件
我的臃肿的ViewController演讲
Square工程师Kat Hawthorne的关于单向数据流的演讲和幻灯片，下面是我引用其中的一张：

上图直观描述了Ziggurat的单向数据流（这里是演示)

一个外部事件触发（例如用户输入）
ViewController通知服务器它收到了用户输入
服务器开始解析或确认此次输入并可能对改变其状态（只有服务器能改变其状态）。然后调用signal()方法
signal（）方法通知渲染器开始更新
渲染器通知展示者，并生成一个View Model（服务器不会打断循环渲染过程）
渲染器将View Model 传递给View Controller
渲染循环等待下一个外部事件触发

权衡分析优缺点

Ziggurat架构模式解决了MVC App面临的常见问题：

臃肿的View Controller

多层的架构模式为所有功能提供了清晰的根节点，从而避免了臃肿的View Controller

共用数据造成很难调试的Bug

减少了无状态性和易变性：服务器层封装了易变的发生（将它限制在主线程上），并且展现者和渲染都是无状态的和单向的。使用依赖注入代替了公用状态和全局单例。

太多责任导致难以测试

更加瘦小的分层使责任分布得更均匀

带来的改进

Ziggurat以很多方式优化了我们的生活，它使小团队的工程师们（从没有经验到几年经验）可以在很短的期限内完成任务。

首先，它通过给工程师在面对新代码库时提供指导和保护性措施的方式，清晰地定义了App的层级和角色。新工程师对它的上手时间很短，因为每个组件都定义的很明确并且符合人们的直观感觉。其次，Ziggurat模式非常易于测试。例如，可以用View Model层来将数据以目标结构输出。这点在MVC中是无法实现的。

单向数据流避免了MVC。不可变类型，更小的类（良好的结构），更多的分层减少了工程师们的精力消耗。它可以很简单地以轻松方式来运行你的App，因为View层中不必包含业务逻辑；所有的业务逻辑都是可测试的而不要View层；View的状态可以通过View Model层在某一时间点的快照来重新创建。最后，我们发现这使得App变得非常轻便。多亏了这种分层的方式和依赖注入，可以轻松实现代码移植。