DTO的替代 - frankel


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

  1. 从服务层返回一个业务对象
  2. 将 BO 转换为表示层中的 DTO
  3. 从表示层返回 DTO

 
返回实体本身
当实体的属性是需要显示的属性的超集时，不需要聚合其他属性。将实体转换为 DTO 不仅是矫枉过正。它会阻碍性能。
在这种情况下，最好的方法是返回实体本身。
 
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)
));

 
 
Jackson转换器
具体到 JSON，我们可以将提供正确数据的过程委托给序列化框架，例如 Jackson。其背后的想法如下：主要代码像往常一样处理实体，在边缘，杰克逊转换器将其转换为所需的 JSON 结构。
如果需要更少的数据，那就是小菜一碟。如果更多，那么转换器需要额外的依赖项来获取数据。当然，如果这些数据来自同一个数据存储区，那就不是很好，上面的替代方案更相关。如果没有，这是一个选择。
 
GraphQL
最后但并非最不重要的一点是，可以返回完整的实体并让客户端决定哪些数据在其上下文中有意义。
GraphQL就是围绕这个想法构建的：Facebook 创建了它，现在它是完全开源的。它的主要优点是在其之上提供规范和许多特定于语言的实现。
 
banq：使用领域事件替代DTO：用事件替代你的DTO数据结构