0. 写在前面

首先，这是一篇翻译文章，个人建议你可以阅读英文原文Baeldung: The DTO Pattern (Data Transfer Object)，因为个人水平，很多地方翻译的不通顺和晦涩，如果你选择继续往下看，请不要高估了我的英文水平。当然，你也可以对比原文来看。

1. 概览

在这篇教程中，我们将讨论 DTO 模式，它是什么，怎样以及何时使用它们。在最后，希望我们知道如何正确地使用它。

2. DTO模式

DTO 或者说数据传输对象（Data Transfer Objects）是在处理方法中携带数据的对象，**目的是减少方法调用的次数。**Martin Fowler 在他的书Patterns of Enterprise Application Architecture中第一次提出该模式。他解释说该模式的主要目的是通过将一次单一调用的多个参数分批来减少到服务器的往返次数。因而在这样的远程操作中降低网络开销。该实践的其它好处是序列化的逻辑（转换对象结构和数据为一种能被存储和传输的指定格式的机制）的封装。它提供了在序列化细微差别中一个单一改变点。它也解耦了表示层的领域模型，允许它们独自改变。

3. 怎样使用它

DTOs 一般被创建为 POJOs。它们是平整的数据结构，不包含业务逻辑，仅仅有存储、访问和最终关联序列化或解析的方法。数据从领域模型映射为 DTO，一般通过在表示层或门面层的 mapper 组件。下方的图片说明了组件间的交互：

4. 何时使用它

正如它的定义中提到的，DTO 在带有远程调用的系统中出现，因为它帮助减少了调用的次数。当领域模型有多种不同对象组成，并且表示层模型甚至一次需要它们的全部数据时，DTO 也能帮忙减少在客户端和服务器间的往返。使用 DTO，我们能从领域模型中构建不同的视角，允许我们创造相同域但优化它们为不影响域设计的客户端的需求的其它表示。这样的灵活性是一个解决复杂问题的强力工具。

5. 使用事例

为了展示这个模式的实现，我们将使用一个有两个主要领域模型的简单应用。在这个事例中，User和Role，为了专注于该模式，让我们看两个功能性的例子，获取用户和创建新用户。

5.1 DTO vs. Domain

下方定义了这两个模型：

public class User {private String id;private String name;private String password;private List<Role> roles;public User(String name, String password, List<Role> roles) {this.name = Objects.requireNonNull(name);this.password = this.encrypt(password);this.roles = Objects.requireNonNull(roles);}// Getters and SettersString encrypt(String password) {// encryption logic}
}

public class Role {private String id;private String name;// Constructors, getters and setters
}

现在，让我们看看 DTO，以便于和领域模型比较。此时，重点关注的是 DTO 表示发送自或发送至 API 客户端的模型。因此，这些小差异要么是为了打包请求发送到服务器，要么是优化客户端的响应。

public class UserDTO {private String name;private List<String> roles;// standard getters and setters
}

上方的 DTO 仅仅提供了到客户端的相关信息，隐藏了密码，比如出于安全原因。接下来的对象组织了全部必要的数据在一次请求中来创建一个用户和发送它到服务器。并且之前提到的，这优化了 API 的交互。看看下面的代码：

public class UserCreationDTO {private String name;private String password;private List<String> roles;// standard getters and setters
}

5.2 连接两端

接下来，绑定两类的 layer 使用一个 mapper 组件去传递从一端到另一端，反之也是。这通常发生在表示层，就像下面展示的：

@RestController
@RequestMapping("/users")
class UserController {private UserService userService;private RoleService roleService;private Mapper mapper;// Constructor@GetMapping@ResponseBodypublic List<UserDTO> getUsers() {return userService.getAll().stream().map(mapper::toDto).collect(toList());}@PostMapping@ResponseBodypublic UserIdDTO create(@RequestBody UserCreationDTO userDTO) {User user = mapper.toUser(userDTO);userDTO.getRoles().stream().map(role -> roleService.getOrCreate(role)).forEach(user::addRole);userService.save(user);return new UserIdDTO(user.getId());}}

最后，我们创建 Mapper 组件来转换数据确保 DTO 和领域模型都不必知道对方：

@Component
class Mapper {public UserDTO toDto(User user) {String name = user.getName();List<String> roles = user.getRoles().stream().map(Role::getName).collect(toList());return new UserDTO(name, roles);}public User toUser(UserCreationDTO userDTO) {return new User(userDTO.getName(), userDTO.getPassword(), new ArrayList<>());}
}

6. 常见错误

虽然 DTO 模式是一种相当简单的设计模式，但是一些错误在实现了这一技巧的应用中被频繁地发现。

第一个是对每一个情形创建不同的 DTO。这将会增加我们需要维护的类和 mapper 们的数量。尝试去保持它们简洁，并且尝试对添加一个新的 DTO 和重用现有的 DTO 做一个权衡。

反向也是有效的。避免对于许多场景使用一个结构简单的类（个人理解：将多个 DO 塞进一个 DTO），这种实践将会导致 DTO 中的许多属性很少被用到，此时，DTO 就像是一个大合同。

其它的常见错误是增加业务逻辑到 DTO 里。这不应该发生。这个模式的目的是优化数据传输和通信协议的结构。因此，全部的业务逻辑都应该在 domain 层。

最后，我们是称作 LocalDTO 的使用，它表示 DTO 传递数据跨过多个域。再一次出现的问题是维护全部映射的成本。支持这种方法的最常见的论点之一是域模型的封装。但实际上，这里的问题是领域模型和持久化模型耦合在一起。通过解耦它们，暴露领域模型的风险基本消失。不过，其它的模式遇到了类似的结果，但是它们通常被使用在更复杂的场景，如 CQRS、Data Mappers、CommandQuerySeparation 等。