Блог

Главная - Вопросы по программированию - Зачем нам нужны какие-либо проводки типа, отличные от тех, которые используются для запросов?

Зачем нам нужны какие-либо проводки типа, отличные от тех, которые используются для запросов?

#java #graphql #graphql-java

Вопрос:

В документе реализации Java GraphQL тип подключения выполняется, как показано ниже, который содержит один для human запроса и один для friends поля Human типа, как выделено.

введите описание изображения здесь

Мне интересно, какая польза от последнего, того, что для friends поля Human типа.

Я думаю, что мы уже возвращаем весь Human объект, включая friends поле , в проводке первого типа с использованием StarWarsData.getHumanDataFetcher() , тогда зачем нам нужен последний?

Спасибо!

Схема выглядит следующим образом:

введите описание изображения здесь
введите описание изображения здесь

Ответ №1:

friends Поле имеет тип Character[] . Когда вы возвращаете определенный тип, поля , которые не имеют встроенного скалярного типа (например String , который является встроенным Character , а который нет), требуют для извлечения собственного средства выборки. Однако вы можете определить DTO, которое моделирует Human тип, и smart graphql.schema.PropertyDataFetcher , предоставляемый graphql-java, должен извлекать поля вашего POJO, поскольку он знает, как следовать шаблонам POJO на основе имени поля.

Комментарии:

1. Но не могу ли я просто вернуть весь Human объект, включая friends использование StarWarsData.getHumanDataFetcher() ?

2. Набор данных предоставляет данные для поля. Поэтому в каждом определении поля должен быть приемник данных. Если поле не содержит определенного набора данных, вместо него используется набор свойств. Human использует встроенные средства выборки для ID , name и homePlanet поскольку они имеют встроенные скалярные типы, но для них потребуются специальные средства выборки friends , поскольку Character не является одним из таких встроенных типов.

3. Я искренне ценю ваш ответ, но я думаю, что на самом деле это не по делу. Если StarWarsData.getHumanDataFetcher() возвращает DTO , содержащий поле с именем friends , значение по умолчанию PropertyDataFetcher должно иметь возможность его извлечь, поэтому причиной для конкретного набора данных должно быть что-то другое.

4. PropertyDataFetcher используется только в том случае, если нет конкретного сборщика данных, как я уже говорил в своем предыдущем комментарии. Я не думаю, что мы можем знать причину наличия определенного набора данных для friends в этом случае, не зная деталей реализации (возможно Human , у вас нет DTO, который правильно моделирует тип, и, следовательно, не будет работать PropertyDataFetcher?). Это может быть вопросом предпочтений разработчика, может быть вопросом конкретной потребности, которую покрывает пользовательский набор данных (но нам об этом не говорят), может быть просто выбором стиля для примера.

5. Я думаю, что то, что я хотел бы узнать, — это рассуждения за полями. Ака, почему некоторые реализации предпочитают не включать friends поле в DTO и создавать отдельный набор данных? Я имею в виду, что если DTO охватывают все поля, мы используем только сборщики данных для запросов и мутаций, но не какие-либо поля, разве это не чище?

Метки: , ,