点击“终码一生”，关注，置顶公众号
每日技术干货，第一时间送达！
我相信（并且仍然相信）它应该成为过去。然而，它的使用似乎仍然很普遍。
我不否认转换数据有一些正当理由。但是，传统的 DTO 流程还有其他替代方案：
-
从服务层返回一个业务对象
请注意，我之前从事的项目，我们直接将 BO 映射到从数据库读取的实体。
-
将 BO 转换为表示层中的 DTO
-
从表示层返回 DTO
1、返回实体本身
当实体的属性是需要显示的属性的超集时，不需要聚合其他属性。将实体转换为 DTO 不仅是矫枉过正。它会阻碍性能。
在这种情况下，最好的方法是返回实体本身。
2、JPA 投影
我们在特定情况下请求特定数据。因此，当调用到达数据访问层时，所需数据的范围是完全已知的：执行适合此范围的 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)
));3、Jackson 转换器
具体到 JSON，我们可以将提供正确数据的过程委托给序列化框架，例如 Jackson。其背后的想法如下：主要代码像往常一样处理实体，在边缘，杰克逊转换器将其转换为所需的 JSON 结构。
如果需要更少的数据，那就是小菜一碟。如果更多，那么转换器需要额外的依赖项来获取数据。当然，如果这些数据来自同一个数据存储区，那就不是很好，上面的替代方案更相关。如果没有，这是一个选择。
4、GraphQL
最后但并非最不重要的一点是，可以返回完整的实体并让客户端决定哪些数据在其上下文中有意义。
GraphQL就是围绕这个想法构建的：Facebook 创建了它，现在它是完全开源的。它的主要优点是在其之上提供规范和许多特定于语言的实现。
API 的查询语言
5、结论
当业务模型和演示模型之间存在差距时，很容易回到古老的“模式”，例如 DTO。但是，上述任何替代方案都可能更相关。
PS：防止找不到本篇文章，可以收藏点赞，方便翻阅查找哦
