微服务Restful API-是否有DTO？

Question

REST API-是否有DTO？

我想在微服务的背景下再次提出这个问题。这是原始问题的报价。

我目前正在为一个项目创建REST-
API，并且一直在阅读有关最佳实践的文章。许多人似乎反对DTO，只是公开域模型，而其他人似乎认为DTO（或用户模型或任何您想称呼的东西）是不好的做法。我个人认为这篇文章很有道理。

但是，我还了解了所有其他映射代码，域模型与其DTO对应对象100％相同的DTO的缺点。

我更倾向于在应用程序的所有层中使用一个对象（换句话说，只公开域对象而不是创建DTO并手动复制每个字段）。我的Rest合同与域对象之间的差异可以使用Jackson注释（如@JsonIgnoreor
@JsonProperty(access = Access.WRITE_ONLY)或@JsonViewetc）解决。或者，如果有一个或两个字段需要使用杰克逊注释无法完成的转​​换，那么我将编写自定义逻辑来处理该问题（相信我，我有5年以上从未遇到过这种情况）长期的休息服务）

我想知道是否由于未将域复制到DTO而错过任何真正的不良影响

Answer 1

只公开域对象的优点

1. 您编写的代码越少，产生的错误也越少。
   • 尽管在我们的代码库中有大量（可争论的）测试用例，但由于从域到DTO或从DTO到反向的字段复制遗漏/错误，我还是遇到了bug。
2. 可维护性-减少锅炉板代码。
   • 当然，如果必须添加新属性，则不必添加Domain，DTO，Mapper和测试用例。不要告诉我这可以通过使用反射beanCopy utils来实现，它违背了整个目的。
   • 我知道Lombok，Groovy，Kotlin，但这只会让我省却吸气剂的困扰。
3. 干燥
4. 性能
   • 我知道这属于“过早的性能优化是万恶之源”的范畴。但这仍然可以节省一些CPU周期，因为不必每次请求至少创建一个（至少以后）一个对象（然后进行垃圾回收）

缺点

1. 从长远来看，DTO将为您提供更大的灵活性
   • 如果我需要这种灵活性。至少，到目前为止，我遇到的都是对HTTP的CRUD操作，我可以使用几个@JsonIgnores进行管理。或者，如果有一个或两个字段需要使用杰克逊注释无法完成的转​​换，正如我之前所说，我可以编写自定义逻辑来处理该问题。
2. 域对象因注释而肿。
   • 这是一个有效的担忧。如果我使用JPA或MyBatis作为持久性框架，则域对象可能具有这些注释，那么也将有Jackson注释。就我而言，这不太适用，我使用的是Spring boot，可以通过使用应用程序范围的属性（如mybatis.configuration.map-underscore-to-camel-case: true，spring.jackson.property-naming-strategy: SNAKE_CASE

简短的故事
，至少就我而言，缺点并没有超过优点，因此通过使用新的POJO作为DTO来重复自己毫无意义。更少的代码，更少的错误机会。因此，继续公开Domain对象并且没有单独的“
view”对象。

免责声明 ：这可能适用于您的用例，也可能不适用。此观察是根据我的用例（基本上是具有15ish端点的CRUD api）