如何解决依赖注入中UserService与RequestService的循环调用问题？

除了抽离共用代码到第三方类，还有以下几种可行方案：

1. 使用Lazy<T>延迟初始化 #

通过Lazy<T>包装依赖，让DI容器在初始化服务时不立即创建依赖实例，而是在第一次使用依赖时才完成实例化，从而打破循环引用链。

修改RequestService的实现：

public class RequestService : IRequestService
{
    private readonly ReviewCustomersContext _context;
    private readonly Lazy<IUserService> _userService;
    private readonly IMapper _mapper;

    public RequestService(ReviewCustomersContext context, Lazy<IUserService> userService, IMapper mapper)
    {
        _context = context;
        _userService = userService;
        _mapper = mapper;
    }

    // 调用UserService方法时，通过.Value获取实例
    public void ProcessRequest(int userId)
    {
        var userService = _userService.Value;
        var user = userService.GetUserById(userId);
        // 后续业务逻辑
    }
}

只需在其中一方使用Lazy<T>即可打破循环，这种方式保留了构造函数注入的优势，同时避免了循环初始化问题。

2. 使用服务定位器模式 #

注入IServiceProvider，在需要调用依赖服务时再从容器中获取实例，而非在构造函数中直接注入依赖。

修改UserService的实现：

public class UserService : IUserService
{
    private readonly ReviewCustomersContext _context;
    private readonly IMapper _mapper;
    private readonly IServiceProvider _serviceProvider;
    private readonly IReviewService _reviewService;
    private readonly IDocumentService _documentService;
    private readonly IDeleteRequestService _deleteRequestService;

    public UserService(ReviewCustomersContext context, IMapper mapper, IServiceProvider serviceProvider, IReviewService reviewService,
        IDocumentService documentService, IDeleteRequestService deleteRequestService)
    {
        _context = context;
        _mapper = mapper;
        _serviceProvider = serviceProvider;
        _reviewService = reviewService;
        _documentService = documentService;
        _deleteRequestService = deleteRequestService;
    }

    // 需要使用RequestService时从容器获取
    public void UpdateUserRequests(int userId)
    {
        var requestService = _serviceProvider.GetRequiredService<IRequestService>();
        requestService.UpdateUserRelatedRequests(userId);
        // 后续业务逻辑
    }
}

注意：这种方式会隐藏服务的依赖关系，降低代码的可测试性，仅适合临时解决问题或特殊场景。

3. 重构服务调用方向 #

梳理两个服务的业务逻辑，将互相调用的逻辑移至外部协调层（如控制器、业务协调类），让两个服务不再直接依赖彼此。

例如，原本由服务互相调用的逻辑，改为由控制器协调：

// 控制器示例
[ApiController]
[Route("api/users")]
public class UserController : ControllerBase
{
    private readonly IUserService _userService;
    private readonly IRequestService _requestService;

    public UserController(IUserService userService, IRequestService requestService)
    {
        _userService = userService;
        _requestService = requestService;
    }

    [HttpPut("{userId}/requests")]
    public IActionResult UpdateUserRequests(int userId)
    {
        var user = _userService.GetUserById(userId);
        _requestService.UpdateUserRelatedRequests(user.Id, user.Status);
        return Ok();
    }
}

这种方式从根源上消除循环依赖，同时让服务职责更清晰，是推荐的长期解决方案。

4. 使用属性注入（部分DI容器支持） #

将其中一个服务的依赖从构造函数注入改为属性注入，让DI容器在创建服务实例后再注入属性依赖，避免构造阶段的循环。

修改RequestService的实现：

public class RequestService : IRequestService
{
    private readonly ReviewCustomersContext _context;
    private readonly IMapper _mapper;

    // 声明可注入的属性
    public IUserService UserService { get; set; }

    public RequestService(ReviewCustomersContext context, IMapper mapper)
    {
        _context = context;
        _mapper = mapper;
    }

    public void ProcessRequest(int userId)
    {
        var user = UserService.GetUserById(userId);
        // 后续业务逻辑
    }
}

需在DI容器配置中启用属性注入（如ASP.NET Core需手动配置或使用Autofac等第三方容器）。这种方式简单但存在风险：属性可能未被注入导致空引用，且不符合构造函数注入的最佳实践，仅适合可选依赖场景。

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