微服务Restful API-是否DTO？
我想在微服务的背景下再次提出这个问题。这是原始问题的报价。
我目前正在为一个项目创建REST-
API，并且一直在阅读有关最佳实践的文章。许多人似乎反对DTO并只是公开域模型，而其他人似乎认为DTO（或用户模型或任何您想称呼的东西）是不好的做法。我个人认为这篇文章很有道理。
但是，我还了解了所有其他映射代码，域模型与其DTO对应对象100％相同的DTO的缺点。
现在，我的问题
我更倾向于在应用程序的所有层中使用一个对象（换句话说，只公开域对象而不是创建DTO并在每个字段上手动复制）。我的合同与代码之间的差异可以使用Jackson注释（如@JsonIgnore或`@JsonProperty(access
Access.WRITE_ONLY)或@JsonView`等）解决。或者，如果有一个或两个字段需要使用杰克逊注释无法完成的转换，那么我将编写自定义逻辑来处理该问题（相信我，我有5年以上的经验，甚至从未遇到过这种情况）长期的休息服务）
我想知道是否由于未将域复制到DTO而错过任何真正的不良影响
回答：
只公开域对象的优点
- 您编写的代码越少，产生的错误也越少。
- 尽管在我们的代码库中有大量（可争论的）测试用例，但由于从域到DTO或反之亦然的字段复制遗漏/错误，我还是遇到了一些错误。
- 可维护性-减少锅炉板代码。
- 如果必须添加新属性，则不必添加Domain，DTO，Mapper和测试用例。不要告诉我这可以使用反射beanCopy utils来实现，它违背了整个目的。
- 我知道Lombok，Groovy和Kotlin，但这只会让我省却吸气剂的困扰。
- 干燥
- 性能
- 我知道这属于“过早的性能优化是万恶之源”的范畴。但这仍然可以节省一些CPU周期，而不必每次请求至少创建（至少）一个对象（然后进行垃圾回收）
缺点
- 从长远来看，DTO将为您提供更大的灵活性
- 如果我需要这种灵活性。至少，到目前为止，我遇到的都是对HTTP的CRUD操作，我可以使用几个@JsonIgnores来进行管理。或者，如果有一个或两个字段需要使用杰克逊注释无法完成的转换，正如我之前所说，我可以编写自定义逻辑来处理该问题。
- 域对象因注释而肿。
- 这是一个有效的担忧。如果我使用JPA或MyBatis作为持久性框架，则域对象可能具有这些注释，那么也将有Jackson注释。就我而言，这不太适用，我使用的是Spring boot，我可以通过使用应用程序范围的属性（如
mybatis.configuration.map-underscore-to-camel-case: true，spring.jackson.property-naming-strategy: SNAKE_CASE
- 这是一个有效的担忧。如果我使用JPA或MyBatis作为持久性框架，则域对象可能具有这些注释，那么也将有Jackson注释。就我而言，这不太适用，我使用的是Spring boot，我可以通过使用应用程序范围的属性（如
，至少就我而言，缺点并没有超过优点，因此以新的POJO作为DTO来重复自己毫无意义。更少的代码，更少的错误机会。因此，继续公开Domain对象并且没有单独的“
view”对象。
：这可能适用于您的用例，也可能不适用。此观察是根据我的用例（基本上是具有15ish端点的CRUD api）
以上是 微服务Restful API-是否DTO？ 的全部内容， 来源链接： utcz.com/qa/428983.html
