微服务Restful API - DTO或不？ [英] Microservices Restful API - DTOs or not?
问题描述
我想在微服务的背景下重新提出这个问题。这是原始问题的引用。
I would like to re-ask this question in Microservices' context. Here is the quote from original question.
我目前正在为一个项目创建一个REST-API并且一直在阅读
文章关于最佳做法的文章。许多人似乎反对
DTO，只是公开域名模型，而其他人似乎认为DTO（或用户模型或任何你想要称之为的）是坏b $ b的做法。就个人而言，我认为这篇文章很有意义。
I am currently creating a REST-API for a project and have been reading article upon article about best practices. Many seem to be against DTOs and simply just expose the domain model, while others seem to think DTOs (or User Models or whatever you want to call it) are bad practice. Personally, I thought that this article made a lot of sense.
但是，我也理解DTO与所有额外的
映射代码，域模型的缺点可能与他们的
DTO对应物100％相同，等等。
However, I also understand the drawbacks of DTOs with all the extra mapping code, domain models that might be 100% identical to their DTO-counterpart and so on.
现在，我的问题
我更倾向于在我的应用程序的所有层中使用一个Object（换句话说，只是暴露域对象而不是创建DTO并手动复制每个字段）。我可以使用杰克逊注释来解决合同与代码之间的差异，例如 @JsonIgnore 或 @JsonProperty（access = Access.WRITE_ONLY）或 @JsonView 等）。或者如果有一个或两个字段需要使用Jackson Annotation无法完成的转换，那么我将编写自定义逻辑来处理这个问题（相信我，在我5年多的时间里，我甚至都没有遇到过这种情况休息服务中的长途旅行）
Now, My question
I am more aligned towards using one Object through all the layers of my application (In other words, just expose Domain Object rather than creating DTO and manually copying over each fields). And the differences in my contract vs code can be addressed using Jackson annotations like @JsonIgnore or @JsonProperty(access = Access.WRITE_ONLY) or @JsonView etc). Or if there is one or two fields that needs a transformation which cannot be done using Jackson Annotation, then I will write custom logic to handle just that (Trust me, I haven't come across this scenario not even once in my 5+ years long journey in Rest services)
我想知道我是否遗漏任何真正的不良影响，因为没有将域名复制到DTO
I would like to know if I am missing any real bad effects for not copying the Domain to DTO
推荐答案
暴露域对象的优点
The Pros of Just exposing Domain Objects
- 你编写的代码越少，你产生的错误越少。
- 尽管我们的代码库中有大量（可论证的）测试用例，但由于从域到DTO的错误/错误复制字段，我遇到了错误或反之亦然。
- 如果我必须添加新属性，我当然不必添加Domain，DTO，Mapper和测试用例。不要告诉我这可以使用反射beanCopy utils来实现，它打败了整个目的。
- 龙目岛，Groovy，Kotlin我知道，但这只会让我感到头疼。
- 我知道这属于过早的性能优化是所有人的根源邪恶。但是这仍然会节省一些CPU周期，因为每次请求不需要创建（以及后来垃圾收集）一个或多个对象（至少）
缺点
Cons
- 从长远来看，DTO将为您提供更多灵活性
- 如果我只需要这种灵活性。至少，无论我到目前为止遇到的是对http的CRUD操作，我可以使用@JsonIgnores来管理。或者，如果有一个或两个字段需要使用Jackson Annotation无法完成的转换，正如我之前所说，我可以编写自定义逻辑来处理这个问题。
- 这是一个有效的问题。如果我使用JPA或MyBatis作为我的持久框架，域对象可能会有这些注释，那么也会有Jackson注释。在我的情况下，这不太适用，但我使用Spring启动，我可以使用应用程序范围的属性，如
mybatis.configuration.map-underscore-to-camel-case：true，spring.jackson.property-naming-strategy：SNAKE_CASE
- This is a valid concern. If I use JPA or MyBatis as my persistent framework, domain object might have those annotations, then there will be Jackson annotations too. In my case, this is not much applicable though, I am using Spring boot and I can get away by using application-wide properties like
mybatis.configuration.map-underscore-to-camel-case: true,spring.jackson.property-naming-strategy: SNAKE_CASE
短篇小说，至少在我的情况下，缺点不会超过专业人士，所以重复没有任何意义我有一个新的POJO作为DTO。代码减少，错误机会减少。因此，继续公开Domain对象而没有单独的view对象。
Short story, at least in my case, cons doesn't outweigh the pros, so it doesn't make any sense to repeat myself by having a new POJO as DTO. Less code, less chances of bugs. So, going ahead with exposing the Domain object and not having a separate "view" object.
免责声明：这可能适用也可能不适用在你的用例中。这个观察结果是我的用例（基本上是一个有15个端点的CRUD api）
Disclaimer: This may or may not be applicable in your use case. This observation is per my usecase (basically a CRUD api having 15ish endpoints)
这篇关于微服务Restful API - DTO或不？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
