Questions about DI patterns

[naratteu]

Hello, I'm currently looking into introducing GraphQL into my solution for the first time.
Upon analyzing a sample project, I noticed that the library utilizes the dependency injection pattern of .NET, yet requires separate injections for each static function listed in the classes to be used as schemas.
If the required objects are limited, the following code design may be cleaner.
Is there a reason why the current code style is being used?

[before gpt translation]
안녕하세요, 제 솔루션에 처음으로 GraphQL을 도입해보기해 알아보는중입니다.
샘플 프로젝트를 분석해보니, 라이브러리가 닷넷의 의존성 주입패턴을 이용하면서도, 스키마로 활용할 클래스에 열거된 정적 함수마다 별도로 주입하도록 되어있는데,
필요한 객체가 한정적이라면, 아래와같은 코드디자인이 더 깔끔할것 같습니다.
지금과같은 코드스타일을 써야하는 이유가 있나요?

[Shane32]

To understand better, take a look at the Message class. I'm going to add a Replies method for discussion purposes also.

public class Message
{
    [Id]
    public int Id { get; set; }

    [Name("Message")]
    public string Value { get; set; } = null!;

    public string From { get; set; } = null!;

    public DateTime Sent { get; set; }

    public IEnumerable<Message> Replies([FromServices] IChat chatService)
        => chatService.GetReplies(this);
}

What you will notice is that the Message class is a data model, not a service. It can contain service-like methods, but it's a data model with service methods layered on top. It would not make sense to have the Message class use DI to inject IChat.

So that is how the AutoRegisteringObjectGraphType class functions - it converts data models into graph types, which may contain methods as well as data properties.

This is applied to all types in the type-first coding model - but it affects the Query type and mutation types most oddly. Let's discuss the Query type. Does the Query type have a data model? Actually yes, ExecutionOptions.Root is the data model provided to the query type - but typically this is null. An example of this would be if the Query type was a data model containing the authenticated user. (This is a poor example, just to illustrate a point.)

class Query
{
    public User AuthenticatedUser { get; set; }
}

class User
{
    public string Name { get; set; }

    public IEnumerable<Message> Messages([FromServices] IChat chatService)
        => chatService.GetMessageFromUser(Name);
}

// during initialization:
ExecutionOptions.Root = new Query(new User("Sample User"));

So now we understand why the query uses static methods - because by default Root is null and an exception would occur when trying to resolve any members. And we also understand why DI is not used; it is a data model, not a service.

Personally, I would agree with you that for the root Query type and nearly all mutation types, it would be better if the graphs were built "from DI". As such I suggest you check out this library which I have written as a side project. I typically use it for all mutation graph types, while query graph types would be built from data models as shown above.

• https://github.com/Shane32/GraphQL.DI
• https://www.nuget.org/packages/Shane32.GraphQL.DI

The above library makes GraphQL act more like a ASP.NET MVC controller, where the controller is resolved by DI and then the proper method executed. Rewriting the Query from the GraphQL.Server sample chat project would result in this:

public class QueryType : DIObjectGraphType<Query> { }
public class Query : DIObjectGraphBase<object>
{
    private readonly IChat _chatService;
    public Query(IChat chatService)
    {
        _chatService = chatService;
    }

    public Message? LastMessage() => _chatService.LastMessage;

    public IEnumerable<Message> AllMessages(string? from = null)
        => from == null ? _chatService.GetAllMessages() : _chatService.GetMessageFromUser(from);

    public int Count() => _chatService.Count;
}

public class MySchema : Schema
{
    public MySchema(IServiceProvider serviceProvider, QueryType query) : base(serviceProvider)
    {
        Query = query;
    }
}

// use .AddDIGraphTypes() in startup

Within the Query class above, similar to ASP.NET MVC controllers,

• Source can be used to access IResolveFieldContext.Source (which in this case is ExecutionOptions.Root which is typically null);
• RequestAborted can be used to access IResolveFieldContext.CancellationToken;
• User can be used to access IResolveFieldContext.User;
• Context can be used to access IResolveFieldContext;
• UserContext can be used to access IResolveFieldContext.UserContext; and
• Metrics can be used to access IResolveFieldContext.Metrics.

Sorry no docs, but see the sample project and notable files here:

• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/Sample.csproj
• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/Startup.cs
• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/TodoSchema.cs
• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/GraphTypes/QueryType.cs
• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/GraphTypes/MutationType.cs
• https://github.com/Shane32/GraphQL.DI/blob/master/Sample/GraphTypes/TodoType.cs

[Shane32]

Keep in mind that without using Shane32.GraphQL.DI you could certainly do the following with no other changes to the sample project:

public class Query
{
    private readonly IChat _chatService;
    public Query(IChat chatService)
    {
        _chatService = chatService;
    }

    public Message? LastMessage() => _chatService.LastMessage;

    public IEnumerable<Message> AllMessages(string? from = null)
        => from == null ? _chatService.GetAllMessages() : _chatService.GetMessageFromUser(from);

    public int Count() => _chatService.Count;
}

// in startup:
services.AddSingleton<Query>(); // or AddScoped if necessary
services.AddGraphQL(b => b
    // other stuff
    .ConfigureExecutionOptions(o => o.Root = o.RequestServices.GetRequiredService<Query>())
);

But it won't work if you have both a Query and a Mutation root type set up like this, because within the ConfigureExecutionOptions delegate you won't know if a query or a mutation is being executed.