REST消息和数据传输对象

在企业应用程序体系结构模式中 ，Martin Fowler将数据传输对象 （DTO）定义为：

为了减少方法调用的数量而在进程之间传递数据的对象。

请注意，数据传输对象与数据访问对象（DAO）不同，尽管它们有一些相似之处。 数据访问对象用于从底层持久层隐藏细节。

REST消息是序列化的DTO

在RESTful架构中，通过线路发送的消息是DTO的序列化。

这意味着在构建RESTful系统时，遵循DTO的所有最佳实践非常重要。

例如，福勒写道：

…封装了串行化机制，用于通过网络传输数据。 通过这样封装序列化，DTO可以将逻辑保留在其余代码中，并在需要时提供明确的点来更改序列化。

换句话说，您应该遵循DRY原则，并且在将内部DTO转换为通过网络发送的消息的位置恰好一个。

在JAX-RS中，该位置应位于实体provider中 。 在Spring中，使用的机制是消息转换器 。 请注意，这两个框架都支持几种常用的序列化格式。

遵循此建议，不仅可以更轻松地更改媒体类型（例如，从纯JSON或HAL更改为更成熟的媒体类型，例如Siren，Mason或UBER ）。 它还可以轻松支持多种媒体类型。

反过来，这使您可以在不破坏客户端的情况下切换媒体类型。

您可以继续使用旧媒体类型为旧客户提供服务，而新客户可以利用新媒体类型。

当必须进行向后不兼容的更改时，引入新的媒体类型是发展REST API的一种方法。

DTO不是域对象

领域对象实现了主题专家使用的无处不在的语言 ，因此被发现 。 另一方面，DTO 旨在满足某些非功能性特征（例如性能），并且需要权衡取舍。

这意味着两者的更改理由非常不同，并且遵循“ 单一责任原则” ，应该是单独的对象。 因此，盲目地序列化域对象应视为反模式。

这也不意味着您也必须盲目添加DTO。 最好从公开域对象开始，例如使用Spring Data REST并根据需要引入DTO。 与往常一样，过早的优化是万恶之源，您应该根据测量结果进行决策。

关键是要牢记差异。 不要更改域对象以获得更好的性能，而要引入DTO。

DTO没有行为

DTO不应有任何行为； 生活中的目的是在远程系统之间传输数据。

这与域对象非常不同。

有两种在DTO中处理数据的基本方法。

首先是使它们成为不可变的对象，其中所有输入都在构造函数中提供，并且只能读取数据。

这不适用于大型对象，并且不能与序列化框架一起使用。

更好的方法是使所有属性都可写。 由于DTO一定没有逻辑，因此这是可以安全地公开字段并忽略getter和setter的少数情况之一。

当然，这意味着代码的其他部分负责用有意义的属性组合填充DTO。

相反，您应该验证从客户端返回的DTO 。

翻译自: https://www.javacodegeeks.com/2014/12/rest-messages-and-data-transfer-objects.html