GraphQL.NET: как разделить корневой запрос на несколько частей
В настоящее время у меня есть небольшое приложение, которое использует GraphQL для связи с серверной частью ядра .net. В настоящее время у меня есть один корневой запрос, который является обязательным для GraphQL, и я ищу способ разбить его на несколько частей для организации. Мой запрос выглядит следующим образом:
public class ReactToFactsQuery : ObjectGraphType
{
public ReactToFactsQuery(IArticleService articleService,
INewsItemService newsItemService)
{
Field<ArticleType>(
name: "article",
arguments: new QueryArguments(new QueryArgument<IntGraphType> { Name = "id" }),
resolve: context =>
{
var id = context.GetArgument<int>("id");
return articleService.Get(id);
}
);
Field<ListGraphType<ArticleType>>(
name: "articles",
arguments: new QueryArguments(new QueryArgument<IntGraphType>() { Name = "count" }),
resolve: context =>
{
var count = context.GetArgument<int?>("count");
if (count.HasValue)
{
return articleService.GetAll(count.Value);
}
else
{
return articleService.GetAll();
}
}
);
Field<ListGraphType<NewsItemType>>(
name: "newsItems",
arguments: new QueryArguments(
new QueryArgument<IntGraphType>() { Name = "count" },
new QueryArgument<IntGraphType>() { Name = "newsType" }),
resolve: context =>
{
var count = context.GetArgument<int?>("count");
var category = context.GetArgument<int>("newsType");
var newsType = (NewsType)category;
if (count.HasValue)
{
return newsItemService.GetMostRecent(newsType, count.Value);
}
else
{
return newsItemService.GetMostRecent(newsType);
}
}
);
}
}
В настоящее время запрос довольно маленький и управляемый, но по мере роста приложения я легко вижу, что в этом классе определено огромное количество запросов. Существующие текущие имена запросов: article, articles и newsItems. Предпочтительно, я хотел бы создать класс запросов для представления каждого типа модели (т.е. один класс запросов для запросов, связанных со статьей, один для запросов, связанных с новостями, и т. д.).
Я прочитал документацию здесь, однако по какой-то причине я изо всех сил пытаюсь понять пример здесь и как применить его к моему коду.
Вся помощь приветствуется.
Ответы 1
Как говорится в документации, вы можете разбивать запросы на виртуальные группы вот так...
Создание подтипов запросов (ArticlesQueryType), управляющих определенными запросами.
public class RootQuery : ObjectGraphType
{
public RootQuery()
{
Name = "RootQuery";
// defines the articles sub query and returns an empty anonymous type object
// whose only purpose is to allow making queries on the subtype (ArticlesQueryType)
Field<ArticlesQueryType>("articles", resolve: context => new {});
}
}
// defines the articles specific queries
public class ArticlesQueryType: ObjectGraphType
{
public ArticlesQueryType(IArticleService articleService)
{
Name = "ArticlesQuery";
Field<ArticleType>(
name: "article",
arguments: new QueryArguments(new QueryArgument<IntGraphType> { Name = "id" }),
resolve: context =>
{
var id = context.GetArgument<int>("id");
return articleService.Get(id);
});
}
}
Тип запроса GraphQL будет
type RootQuery {
articles: ArticlesQuery
news: NewsQuery
}
type ArticlesQuery {
article(id: ID): Article
articles: [Article]
}
...
С другой стороны, если вы не хотите изменять структуру запроса и имеете только один корень, содержащий конкретные запросы, вы можете для ясности разделить запросы на частичные классы...
public partial class RootQuery: ObjectGraphType
{
private IArticleService ArticleService { get; }
public RootQuery()
{
Name = "RootQuery";
InitializeArticlesQueries()
}
}
а в другом файле (RootQuery_Articles.cs) например
public partial class RootQuery
{
protected InitializeArticlesQuery()
{
Field<ArticleType>(
name: "article",
arguments: new QueryArguments(new QueryArgument<IntGraphType> { Name = "id" }),
resolve: context =>
{
var id = context.GetArgument<int>("id");
return articleService.Get(id);
});
}
}
Таким образом, тип запроса GraphQL будет
type RootQuery {
articles: [Article]
....
}
Я бы добавил, что недостатком использования частичных классов является то, что файл RootQuery по-прежнему раздувается длинным списком зависимостей, если вы используете внедрение конструктора. например если у вас есть более 100 сервисов или репозиториев, то это будет длинный список
А со схемой первого подхода? Я только вижу, что частичный метод - единственный вариант здесь...
Это правильное предположение, что вы создаете все запросы статей. Один для GetOne, GetAll и т. д. внутри ArticlesQueryType?