1

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

为什么做同样烦人的事...

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

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

......两次近距离没有解释？

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

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其他是相同的。实际上，我发现没有其他指南建议甚至提到做 amodel.js而是从type.js.

我能理解如果

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

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

4

2 回答 2

2

它们不是同一件事。只是同一个名字：

  • 一是对象实例
  • 另一个是对象的结构（用于记录 API 的类型）
于 2016-07-03T03:55:42.780 回答
1

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

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

GraphQL 是应用程序中的外部接口层。

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

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

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

于 2016-07-05T18:14:23.287 回答