C#中服务构建前在对象构造中引用服务的问题

授权需求（IAuthorizationRequirement）的设计定位是标记类/数据载体，不建议直接在其构造函数中注入服务。正确的做法是将依赖服务的逻辑移到对应的AuthorizationHandler中，Handler可以通过DI正常注入依赖。

1. 调整授权需求类 #

让GameGroupsAuthorisationConnectRequirement仅作为标记，不包含服务依赖：

public class GameGroupsAuthorisationConnectRequirement : IAuthorizationRequirement
{
    // 若需传递固定配置参数，可在此添加属性，无需注入服务
}

2. 创建授权处理器类 #

创建继承自AuthorizationHandler<TRequirement>的处理器，在构造函数中注入RunningGameService，并实现授权逻辑：

public class GameGroupsAuthorisationConnectHandler : AuthorizationHandler<GameGroupsAuthorisationConnectRequirement>
{
    private readonly RunningGameService _runningGameService;

    // 通过构造函数注入依赖服务
    public GameGroupsAuthorisationConnectHandler(RunningGameService runningGameService)
    {
        _runningGameService = runningGameService;
    }

    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, GameGroupsAuthorisationConnectRequirement requirement)
    {
        // 在这里使用_runningGameService执行授权判断逻辑
        // 示例：检查当前用户是否允许连接游戏组
        bool isAuthorized = _runningGameService.CheckUserGameGroupAccess(context.User);
        
        if (isAuthorized)
        {
            context.Succeed(requirement); // 授权通过
        }

        return Task.CompletedTask;
    }
}

3. 更新DI注册 #

在服务注册中添加授权处理器的注册，同时保留原有策略配置：

builder.Services.AddSingleton<RunningGameService>();

// 注册授权处理器到DI容器
builder.Services.AddSingleton<IAuthorizationHandler, GameGroupsAuthorisationConnectHandler>();

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("GameGroupsAuthorisationConnect", policy =>
    {
        policy.Requirements.Add(new GameGroupsAuthorisationConnectRequirement());
    });
});

为什么不直接在Requirement中注入服务？ #

• 违背单一职责原则：Requirement的职责是定义授权规则的“是什么”，而Handler负责处理“怎么验证”。
• DI容器限制：直接在Requirement构造函数中注入服务会导致注册策略时无法通过DI解析依赖（因为AddPolicy中是直接new Requirement）。

内容的提问来源于stack exchange，提问作者ArmanP