使用 GraphQL，声明一个与 GraphQL“类型”没有任何明显差异的支持模型“类”有啥好处或必要性？

Posted 2023-03-08

【中文标题】使用 GraphQL，声明一个与 GraphQL“类型”没有任何明显差异的支持模型“类”有啥好处或必要性？

【英文标题】：With GraphQL, what is the benefit or necessity of declaring a backing model "class" that does not vary from the GraphQL "Type" in any obvious way?使用 GraphQL，声明一个与 GraphQL“类型”没有任何明显差异的支持模型“类”有什么好处或必要性？

【发布时间】：2016-11-04 18:08:22

【问题描述】：

我喜欢 Universal Relay 样板 - 总的来说，我可以说他们非常周到地考虑如何将整个东西放在一起，不像大多数样板，文件夹组织等似乎是事后才想到的（我猜是因为你赢了'起初不做任何重要的事情，或其他事情）......但不是URB。或者至少我们对同样的事情很挑剔。

为什么same annoying thing...

...除了一件事：我不明白他们为什么这样做。

// Class used by GraphQL Server
export default class User

  constructor( fields )
  
    this.id = fields.id
    this.User_AccountName = fields.User_AccountName
    this.User_AccountPassword = fields.User_AccountPassword
    this.User_DisplayName = fields.User_DisplayName
    this.User_ProfilePhoto = fields.User_ProfilePhoto
    this.User_Email = fields.User_Email
    this.User_PhoneNumberMobile = fields.User_PhoneNumberMobile
    this.User_Locale = fields.User_Locale
    this.UserToken2 = fields.UserToken2
  

...two times in close proximity with no explanation?

这里是“类型”，实际上由于别名而与原来的有点不同。

export default new GraphQLObjectType( 
  name: 'Viewer',
  interfaces: [NodeInterface],
  isTypeOf: object => object instanceof User,
  fields: 
    id: globalIdField('Viewer'),

    User_IsAnonymous:         type: GraphQLBoolean, resolve: (obj) => obj.id.equals( Uuid_0 ) ,
    User_AccountName:         type: GraphQLString,  resolve: (obj) => obj.User_AccountName ,
    User_DisplayName:         type: GraphQLString,  resolve: (obj) => obj.User_DisplayName ,
    User_ProfilePhoto:        type: GraphQLString,  resolve: (obj) => obj.User_ProfilePhoto ,
    User_Email:               type: GraphQLString,  resolve: (obj) => obj.User_Email ,
    User_PhoneNumberMobile:   type: GraphQLString,  resolve: (obj) => obj.User_PhoneNumberMobile ,
    User_Locale:              type: GraphQLString,  resolve: (obj) => obj.User_Locale ,
    UserToken2:              type: GraphQLString,  resolve: (obj) => obj.UserToken2 ,

    ..._ViewerFields,

  ,
 );

他们显然是有意的

这是我在样板文件中找到的model 和type 之间最显着的区别示例；其他是相同的。实际上我有点恼火的是，没有其他指南推荐甚至提到做 model.js 而是从 type.js 开始。

我能理解

某些类型在安全性、性能、美学、设计等方面需要与模型不同 某些类型故意跨越模型 某些类型出于设计原因封装模型

但是他们到处都这样做，这让我觉得我在这里遗漏了一些重要的东西。

【参考方案1】：

它们不是一回事。同名：

一个是object实例 另一个是对象的结构（用于记录 API 的类型）

【讨论】：

那么...类型是第一位的？

放类然后类型;)

【参考方案2】：

可能只是样板文件没有展示这种方法的好处。我认为您已经有了一些可能有益的想法，例如当您的后端数据模型未完全映射到您的 GraphQL API 时。

如今，许多采用 GraphQL 的组织都有一些他们习惯使用的现有后端和数据模型。在这种情况下，您可以将 GraphQL 视为另一个 API 层，它位于您的 REST API 或其他任何东西旁边。 GraphQL 不是您的实际后端 - 您不应该直接在解析器中处理您的业务逻辑，因为那样您的整个应用程序将与 GraphQL 耦合。当您使用 GraphQL 从头开始​​构建新应用程序时，这一点并不那么清楚，但这是一个很好的模式，因为您将来可能希望灵活地使用您的 API。

在上图中，GraphQL 将是“外部接口”。请注意，它位于业务逻辑/模型层之上，但不会取代它。

GraphQL API 中的类型是您希望在 UI 中显示的数据。这可能包含不在数据库中的计算字段，某些字段可能是从多个后端提取的，等等。

阅读 Dan Schafer 在我的 React Europe 演讲摘要中提出的这些概念：https://medium.com/apollo-stack/graphql-at-facebook-by-dan-schafer-38d65ef075af#.awusd3ibv