DTO 的替代品！！

点击“终码一生”，关注，置顶公众号

每日技术干货，第一时间送达！

数据传输对象是在进程之间承载数据的对象。使用它的动机是进程之间的通信通常通过远程接口完成，其中每次调用都是昂贵的操作。由于每次调用的大部分成本都与客户端和服务器之间的往返时间有关，因此减少调用次数的一种方法是使用一个对象（DTO）来聚合本应传输的数据由几个呼叫，但仅由一个呼叫提供服务。

我相信（并且仍然相信）它应该成为过去。然而，它的使用似乎仍然很普遍。

我不否认转换数据有一些正当理由。但是，传统的 DTO 流程还有其他替代方案：

• 从服务层返回一个业务对象

请注意，我之前从事的项目，我们直接将 BO 映射到从数据库读取的实体。

• 将 BO 转换为表示层中的 DTO

• 从表示层返回 DTO

当实体的属性是需要显示的属性的超集时，不需要聚合其他属性。将实体转换为 DTO 不仅是矫枉过正。它会阻碍性能。

在这种情况下，最好的方法是返回实体本身。

我们在特定情况下请求特定数据。因此，当调用到达数据访问层时，所需数据的范围是完全已知的：执行适合此范围的 SQL 查询是有意义的。

为此，JPA 提供了预测。本质上，查询中的投影允许精确地选择想要的数据。这是一个例子；给定一个Person实体类和一个PersonDetails普通类：

CriteriaQuery<PersonDetails> q = cb.createQuery(PersonDetails.class);
Root<Person> c = q.from(Person.class);
q.select(cb.construct(PersonDetails.class,
  c.get(Person_.firstName),
  c.get(Person_.lastName),
  c.get(Person_.birthdate)
));

具体到 JSON，我们可以将提供正确数据的过程委托给序列化框架，例如 Jackson。其背后的想法如下：主要代码像往常一样处理实体，在边缘，杰克逊转换器将其转换为所需的 JSON 结构。

如果需要更少的数据，那就是小菜一碟。如果更多，那么转换器需要额外的依赖项来获取数据。当然，如果这些数据来自同一个数据存储区，那就不是很好，上面的替代方案更相关。如果没有，这是一个选择。

最后但并非最不重要的一点是，可以返回完整的实体并让客户端决定哪些数据在其上下文中有意义。

GraphQL就是围绕这个想法构建的：Facebook 创建了它，现在它是完全开源的。它的主要优点是在其之上提供规范和许多特定于语言的实现。

API 的查询语言

GraphQL 是一种 API 查询语言，也是一种使用现有数据完成这些查询的运行时。GraphQL 为您的 API 中的数据提供了完整且易于理解的描述，使客户能够准确地询问他们需要什么，仅此而已，使 API 更容易随着时间的推移而发展，并支持强大的开发人员工具。

当业务模型和演示模型之间存在差距时，很容易回到古老的“模式”，例如 DTO。但是，上述任何替代方案都可能更相关。

PS：防止找不到本篇文章，可以收藏点赞，方便翻阅查找哦。