使用 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?

查看:14
本文介绍了使用 GraphQL,声明支持模型“类"有什么好处或必要性?与 GraphQL“类型"没有区别以任何明显的方式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我喜欢 Universal Relay Boilerplate - 总的来说,我可以说他们对如何将整个事情组合在一起非常周到,不像大多数样板,文件夹组织等等似乎是事后的想法(我猜是因为你赢了一开始不要做任何重要的事情,或者什么)......但不是URB.或者至少我们对相同的事情很挑剔.

I like the Universal Relay Boilerplate - in general I can tell they were very thoughtful about how they put this whole thing together, unlike most boilerplates for which folder organization and so on seems to be an intended afterthought (I guess because you won't do anything important at first, or something)... but not URB. Or at least we are picky about the same things.

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

...except for one thing: I don't get why they do this.

// 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?

Here is the "Type" which is actually a bit different than the original by virtue of an alias.

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,

  },
} );

他们显然是故意的

这是我能在样板文件中找到的 modeltype 之间差异的最引人注目的例子;其他是相同的.发现没有其他指南推荐甚至提到做 model.js 而是从 type.js 开始,我实际上有点恼火.

They intend it obviously

This is the most dramatic example of difference between model and type I could find in the boilerplate; the others are identical. I was actually a bit annoyed to find that no other guide recommends or even mentions doing a model.js but rather starts from a type.js.

我能理解如果

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

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

But they do it everywhere which leads me to think I am missing something important here.

推荐答案

它们不是一回事.同名:

They are not the same thing. Just the same name:

  • 一个是对象实例
  • 另一个是对象的结构(用于记录 API 的类型)
  • One is the object instance
  • the other is the structure of the objects (types use to document the API)

这篇关于使用 GraphQL,声明支持模型“类"有什么好处或必要性?与 GraphQL“类型"没有区别以任何明显的方式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆