据我了解，Data Transfer Objects（DTO）通常是小型，扁平，无行为，可序列化的对象，其主要优点是易于跨网络传输。
GraphQL有以下几个方面：
GraphQL和DTO模式是否相互排斥？
以下是导致这个问题的原因：我们设想了一个带网关的微服务架构。我正在设计一个适合该架构的API，以便（除其他事项）geometries之外。在许多（可能是大多数）情况下，几何对客户端应用程序没有用处，但它们在其他应用程序中是至关重要的，因此必须提供服务。然而，它们被序列化，几何形状可能很大，因此客户可以选择拒绝它们可以节省大量带宽。我已经看到处理几何的RESTful API通过在查询字符串中提供"returnGeometry" parameter来实现。我从来没有对这种方法感到完全满意，我最初设想提供一组相当深的相关/嵌套返回对象，其中许多客户将选择拒绝。所有这些都促使我考虑使用GraphQL接口。随着设计的进展，我开始考虑将输出扁平化（全部或部分），这使我考虑了DTO模式。所以现在我想知道是否最好将所有内容压平成DTO并跳过GraphQL（我认为有利于REST？）。我已经考虑过使用GraphQL服务于DTO的中间地点，让客户挑选他们想要的属性，但我想知道这些混合模式是否适用于他们。技术不当。
答案 0 :(得分：2)
我认为有必要区分GraphQL的2个典型用例和结合了前两个的隐藏的第3个用例。
然而，在所有3种情况下，GraphType的本质是有选择地决定要从域实体中公开哪些字段。听起来很熟悉？应该是DTO。不论是否使用GraphQL，例如，您都不想在“用户”表上公开“密码”字段，因此您需要以一种或另一种方式向客户隐藏它。
由于GraphQL不会对持久层做任何假设，而是为您提供了合适的工具来处理您的输入类型/查询，因此启用了此功能。
1。 直接暴露给客户端（例如网络，移动设备）的GraphQL端点：
在这种情况下，您将使用任何GraphQL客户端直接与您的graphql端点进行对话。这里的DTO是实际的GraphType对象，其结构取决于您添加到公开的GraphType中的字段。
在内部，您将使用字段解析器将DTO转换为域实体，然后使用存储库对其进行持久化。
DTO转换发生在GraphType的字段解析器内部。
GraphQL --> DTO --> Domain Entity --> Data Store
2。。暴露给客户端的REST端点，该端点在内部使用GraphQL端点：
在此用例中，您的Web和移动客户端正在通过REST使用传统DTO。但是，控制器正在连接到内部公开的GraphQL端点-与用例＃1相反-用例＃1的GraphType是域实体的精确映射，包括密码字段！
DTO转换发生在控制器 调用端点之前。
DTO --> Domain Entity --> GraphQL --> Data Store
3。结合1和2
这是一个用例，用于当您将体系结构从一种转移到另一种时，并且您不想破坏客户消费者的事情，因此您将两个选项都保留为开放状态，并最终停用其中一个。
希望这会有所帮助！