《架构整洁之道》第 23 章 展示器和谦卑对象

上一章节中，引入了展示器的概念（presenter）。它实际上是采用谦卑对象（humble object）模式的一种形式，这种设计模式可以帮助试别和保护系统架构的边界。上一章节中，介绍的整洁架构就充满了大量的谦卑对象的实现体。

谦卑对象模式

谦卑对象模式最初的设计目的，是为了帮助单元测试的编写者，区分容易测试的行为和难以测试的行为，并将其隔离。其设计思路，就是将这两类行为拆分为两组模块或类。

其中难以测试的行为分组，就叫谦卑组。

例如GUI通常很难写单元测试，因为很难让计算机自行检查屏幕内容。但是GUI中的行为是容易测试的。这个时候我们就可以使用谦卑对象模式，将GUI的这两种行为拆分为展示器，和视图两个部分。

展示器与视图

视图部分属于难以测试的谦卑对象，这种对象的代码通常越简单越好，它只负责将数据填充到GUI上，而不进行任何处理数据的行为。

展示器是可测试的对象，它的工作是从应用程序中接收数据，然后按视图的需要，将数据格式化，以便展示在屏幕上。比如接收的数据是个对象，或者时间戳，那么它的工作就是将其展示为格式化的字符串。比如某一些字段需要标红，那么展示器就要负责给出一个开关布尔值。

也就是说视图只负责展示，一切逻辑应当在展示器中完成。所以我们将视图部分叫做是谦卑的，因为它只接收并展示。

测试与架构

强大的可测试性，是一个架构设计是否优秀的显著衡量标准之一。

谦卑对象模式就是这方面的一个非常好的例子。将系统切分为可测试和不可测试部分的过程中，往往也就定义了系统的架构边界。

展示器与视图之间的边界，只是多种架构边界的一种。

数据库网关

用例交互器，与数据库中间的组件，我们称为数据库网关。上一章节中，UseCaseInteractor就是用例交互器，DataAccessInterface就是数据库网关，这个网关是一个多态接口。包含了应用程序中所有对数据库的增删改查操作。

之前我们说过，SQL不应该出现在用例层的代码中。所以用例层只提供接口，实现则由数据库层来提供。提供的这些实现，也应当做谦卑对象，因为它们只利用SQL或其它数据库提供的接口来访问数据。

但是用例交互器，则不属于谦卑对象，因为它们封装的是系统的业务逻辑。

数据映射器

ORM应当属于数据库层。因为它只是一个简单的数据结构，不包含行为信息。它们只是将数据从关系型数据库加载到了对应的数据结构中。ORM实际上，就是在数据库和数据网关接口之间，构建的一种谦卑对象的边界。

服务监听器

如果我们的程序需要和其他服务进行交互，或者该应用本身自己对外提供服务，我们也能够在相关服务边界处，看到谦卑对象。

我们的程序会将收到的数据，加载到简单的数据结构中，并将数据跨越边界，传递给能够将其格式化的其他外部服务。即，纯监听器就是谦卑对象，只负责接收和和转发。

本章小结

在每个系统架构的边界处，都可能发现谦卑对象的存在。因为跨边界的通信，肯定需要用到某种简单的数据结构，而边界会自然而然的将系统分割成难以测试的部分，和容易测试的部分，所以通过在系统边界运用谦卑对象模式，可以大幅的提高系统的可测试性。