Spring REST API 默认有 4 个 DTO？
4 DTOs by default for Spring REST API?
你好，
几周来我一直在寻找相关的东西，但我没有被说服。
我正在制作一个 RestAPI。
而且，我知道 DTO。
首先请看上图
红色图是我画的部分
除了红色部分，DTO只在Controller-Service之间提到
即问题在解释大部分DTO的例子中提到了只在Controller-Serve之间使用DTO的必要性
但如果你深入挖掘，有人
View(Front) - 你提到你需要一个控制器使用的“单独的”DTO。
这意味着我们已经需要两个独立的 DTO。
接下来，
现在有人说DTO应该分解成RequestDTO和ResponseDTO。
然后我有一个 ControllerRequestDTO 需要从 View 传递到 Controller
应从 Controller 传递到 Service 的 ServiceRequestDTO
之后转化为Entity，工作完成后，返回的Entity必须转化为DTO。
因此，ServiceResponseDTO 在 Service 中创建并传递给 Controller
ControllerResponseDTO 应该从 Controller 发送回 View
我理解应该是.
但是再一次，关于视图控制器所需的 DTO 的信息非常少。
ControllerRequestDTO、ControllerResponseDTO、ServiceRequestDTO、ServiceResposeDTO
共4个。
我做对了吗？
或者您是否在增加不必要的资源？
对此有很多看法。
例如，控制器被视为外部世界与我们的应用程序之间的交互方式。因此，收到的controller request dto直接传给了service层（这样你就不需要service request dto了）。一旦服务执行了所有操作，它就会 returns 服务响应 dto ，控制器直接将其传递给最终用户。
因此，如果您愿意，您可以只有 2 个 dto - 请求 dto 和响应 dto。
但正如我所提到的，这是设计应用程序的一种方式。
软件设计不是一套不需要思考就可以遵循的规则。相反，软件设计是追求目标的一种手段 - 不同的目标可能需要不同的手段。
所以当有人告诉你创建单独的 DTO 时，你应该问（或者实际上，他们应该在没有提示的情况下告诉你）为什么他们推荐这个，所以你可以评估是否他们的目标和情况与您的相符。
由于我不是建议您创建 4 个不同 DTO 的人，我只能推测可能促使这样的建议的目标和情况，但我可以肯定地说这些目标和情况并不普遍，许多应用程序使用更少的 DTO 就可以正常运行。
单独 request/response DTO 的原因：
- 如果字段是 read-only，它们在响应中有意义，但在请求中没有意义。当然，您可以简单地忽略请求中的这些字段，但这可能会让您的 API 的用户感到惊讶，并且实施 API 的任何人都可能会意外使用本应为只读的字段。通过从请求 DTO 中删除这些字段，您消除了这种歧义。
相同 request/response DTO 的原因：
- 简单
- 易用性（客户端可以将他收到的DTO发送回服务器）
不同 rest/service DTO 的原因：
- 您需要使用来自不同 REST 控制器的相同服务，例如，因为您更改了数据协定，但需要保持以前的版本运行，直到所有 API 个客户端都已升级
- 更难意外更改数据合同（这会破坏您的 API 客户）
相同 rest/service DTO 的原因：
- 简单
如您所见，这取决于情况。但是许多应用程序使用相同的 DTO 来处理请求和响应、控制器和服务。只有当你看到这样做有明显好处时，你才应该为自己做额外的工作。
在我看来，这取决于你需要什么。让我们举一些例子。
场景一
你(客户)去餐厅，你看到菜单(查看)，你点了牛排(请求 DTO)。服务员（控制器）将订单交给厨师（服务，存储库，他会做任何他需要做的事来为你做饭）。然后，服务员回来给你一份牛排(response DTO)。
场景二
你(客户)去餐厅，你看到菜单(查看)，然后你从那家餐厅点了牛排，然后来自 Mac Donald's 的汉堡（请求 DTO 1）。服务员（controller）将订单交给厨师（services, repository），但他还需要阅读您的订单并获取正确的项目向 Mac Donald's( 解析您的请求 DTO 1 并创建一个新的 请求 DTO 2 到 打电话给第 3 方 API 去拿一个汉堡，应该是 response DTO 2）。最后，当一切准备就绪后，服务员为您端来了餐厅的牛排和Mac Donald's 汉堡的组合餐（response DTO 1）
也许还有其他情况。但我的意思是它是基于你需要什么以及你如何设计你的系统。而且我觉得应该越简单越好。
在你的图像中，如果你的应用程序不复杂，我认为你可以使用相同的DTO（红色和黑色）。
你好，
几周来我一直在寻找相关的东西，但我没有被说服。
我正在制作一个 RestAPI。 而且，我知道 DTO。
首先请看上图
红色图是我画的部分
除了红色部分，DTO只在Controller-Service之间提到
即问题在解释大部分DTO的例子中提到了只在Controller-Serve之间使用DTO的必要性
但如果你深入挖掘，有人 View(Front) - 你提到你需要一个控制器使用的“单独的”DTO。
这意味着我们已经需要两个独立的 DTO。
接下来， 现在有人说DTO应该分解成RequestDTO和ResponseDTO。
然后我有一个 ControllerRequestDTO 需要从 View 传递到 Controller
应从 Controller 传递到 Service 的 ServiceRequestDTO
之后转化为Entity，工作完成后，返回的Entity必须转化为DTO。
因此，ServiceResponseDTO 在 Service 中创建并传递给 Controller
ControllerResponseDTO 应该从 Controller 发送回 View
我理解应该是.
但是再一次，关于视图控制器所需的 DTO 的信息非常少。
ControllerRequestDTO、ControllerResponseDTO、ServiceRequestDTO、ServiceResposeDTO
共4个。
我做对了吗？
或者您是否在增加不必要的资源？
对此有很多看法。
例如，控制器被视为外部世界与我们的应用程序之间的交互方式。因此，收到的controller request dto直接传给了service层（这样你就不需要service request dto了）。一旦服务执行了所有操作，它就会 returns 服务响应 dto ，控制器直接将其传递给最终用户。
因此，如果您愿意，您可以只有 2 个 dto - 请求 dto 和响应 dto。
但正如我所提到的，这是设计应用程序的一种方式。
软件设计不是一套不需要思考就可以遵循的规则。相反，软件设计是追求目标的一种手段 - 不同的目标可能需要不同的手段。
所以当有人告诉你创建单独的 DTO 时，你应该问（或者实际上，他们应该在没有提示的情况下告诉你）为什么他们推荐这个，所以你可以评估是否他们的目标和情况与您的相符。
由于我不是建议您创建 4 个不同 DTO 的人，我只能推测可能促使这样的建议的目标和情况，但我可以肯定地说这些目标和情况并不普遍，许多应用程序使用更少的 DTO 就可以正常运行。
单独 request/response DTO 的原因：
- 如果字段是 read-only，它们在响应中有意义，但在请求中没有意义。当然，您可以简单地忽略请求中的这些字段，但这可能会让您的 API 的用户感到惊讶，并且实施 API 的任何人都可能会意外使用本应为只读的字段。通过从请求 DTO 中删除这些字段，您消除了这种歧义。
相同 request/response DTO 的原因：
- 简单
- 易用性（客户端可以将他收到的DTO发送回服务器）
不同 rest/service DTO 的原因：
- 您需要使用来自不同 REST 控制器的相同服务，例如，因为您更改了数据协定，但需要保持以前的版本运行，直到所有 API 个客户端都已升级
- 更难意外更改数据合同（这会破坏您的 API 客户）
相同 rest/service DTO 的原因：
- 简单
如您所见，这取决于情况。但是许多应用程序使用相同的 DTO 来处理请求和响应、控制器和服务。只有当你看到这样做有明显好处时，你才应该为自己做额外的工作。
在我看来，这取决于你需要什么。让我们举一些例子。
场景一
你(客户)去餐厅，你看到菜单(查看)，你点了牛排(请求 DTO)。服务员（控制器）将订单交给厨师（服务，存储库，他会做任何他需要做的事来为你做饭）。然后，服务员回来给你一份牛排(response DTO)。
场景二
你(客户)去餐厅，你看到菜单(查看)，然后你从那家餐厅点了牛排，然后来自 Mac Donald's 的汉堡（请求 DTO 1）。服务员（controller）将订单交给厨师（services, repository），但他还需要阅读您的订单并获取正确的项目向 Mac Donald's( 解析您的请求 DTO 1 并创建一个新的 请求 DTO 2 到 打电话给第 3 方 API 去拿一个汉堡，应该是 response DTO 2）。最后，当一切准备就绪后，服务员为您端来了餐厅的牛排和Mac Donald's 汉堡的组合餐（response DTO 1）
也许还有其他情况。但我的意思是它是基于你需要什么以及你如何设计你的系统。而且我觉得应该越简单越好。
在你的图像中，如果你的应用程序不复杂，我认为你可以使用相同的DTO（红色和黑色）。