.NET Core EF Blazor应用中如何避免静态方法并解决循环依赖

一、延迟注入（Lazy Injection） #

直接通过构造函数注入IServiceProvider，在真正需要使用依赖服务时再动态获取，避免构造阶段触发循环依赖。这种方式无需大幅修改现有服务结构，适合快速解决问题。

示例代码：

public class AccountManager
{
    private readonly IServiceProvider _serviceProvider;

    public AccountManager(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task<decimal> CalculateAccountTotal(int accountId)
    {
        // 仅在业务逻辑执行时获取ComputerManager
        var computerManager = _serviceProvider.GetRequiredService<ComputerManager>();
        var computers = await computerManager.GetAccountComputers(accountId);
        
        // 后续计算逻辑...
        return computers.Sum(c => c.Cost);
    }
}

注意：不要在构造函数中调用GetService，必须等到业务方法执行时再获取依赖，否则仍会触发循环。

二、提取最小职责的抽象接口 #

将两个服务互相依赖的特定功能拆分为独立的小接口，而非让整个服务互相依赖。这种方式符合SOLID单一职责原则，既解耦又避免循环。

示例：

// 仅定义AccountManager对外提供的必要信息接口
public interface IAccountInfoProvider
{
    Task<AccountBasicInfo> GetAccountBasicInfo(int accountId);
}

// 仅定义ComputerManager对外提供的成本查询接口
public interface IComputerCostProvider
{
    Task<decimal> GetComputerCost(int computerId);
}

// AccountManager实现IAccountInfoProvider，同时依赖IComputerCostProvider
public class AccountManager : IAccountInfoProvider
{
    private readonly IComputerCostProvider _computerCostProvider;

    public AccountManager(IComputerCostProvider computerCostProvider)
    {
        _computerCostProvider = computerCostProvider;
    }

    public async Task<AccountBasicInfo> GetAccountBasicInfo(int accountId)
    {
        // 实现账户基础信息查询逻辑
    }

    // 其他账户管理业务方法...
}

// ComputerManager实现IComputerCostProvider，同时依赖IAccountInfoProvider
public class ComputerManager : IComputerCostProvider
{
    private readonly IAccountInfoProvider _accountInfoProvider;

    public ComputerManager(IAccountInfoProvider accountInfoProvider)
    {
        _accountInfoProvider = accountInfoProvider;
    }

    public async Task<decimal> GetComputerCost(int computerId)
    {
        // 实现计算机成本查询逻辑
    }

    // 其他计算机管理业务方法...
}

注册服务时，只需将实现类与对应接口绑定即可，完全消除循环依赖。

三、事件驱动/中介者模式 #

引入中介者（如MediatR），让服务通过发送命令/查询来获取数据，而非直接依赖其他服务。服务之间完全解耦，从根源上避免循环依赖。

示例：

// 定义查询模型
public class GetComputerCostQuery : IRequest<decimal>
{
    public int ComputerId { get; set; }
}

// 实现查询处理器（直接操作DbContext或依赖底层服务）
public class GetComputerCostQueryHandler : IRequestHandler<GetComputerCostQuery, decimal>
{
    private readonly IDbContextFactory<AppDbContext> _dbContextFactory;

    public GetComputerCostQueryHandler(IDbContextFactory<AppDbContext> dbContextFactory)
    {
        _dbContextFactory = dbContextFactory;
    }

    public async Task<decimal> Handle(GetComputerCostQuery request, CancellationToken cancellationToken)
    {
        using var dbContext = _dbContextFactory.CreateDbContext();
        var computer = await dbContext.Computers.FindAsync(request.ComputerId, cancellationToken);
        return computer?.Cost ?? 0;
    }
}

// 在AccountManager中使用中介者
public class AccountManager
{
    private readonly IMediator _mediator;

    public AccountManager(IMediator mediator)
    {
        _mediator = mediator;
    }

    public async Task<decimal> CalculateAccountTotal(int accountId)
    {
        // 发送查询获取计算机成本，无需依赖ComputerManager
        var computerCost = await _mediator.Send(new GetComputerCostQuery { ComputerId = 123 });
        
        // 后续计算逻辑...
    }
}

四、直接操作DbContext（谨慎使用） #

如果服务之间的交互只是简单的数据库查询，可直接在服务中注入IDbContextFactory<AppDbContext>，自行查询所需数据，避免依赖其他服务。为避免重复代码，可将通用查询逻辑抽成无状态的扩展方法。

示例：

// 通用数据库查询扩展
public static class ComputerDbExtensions
{
    public static async Task<decimal> GetComputerCostAsync(this AppDbContext dbContext, int computerId)
    {
        var computer = await dbContext.Computers.FindAsync(computerId);
        return computer?.Cost ?? 0;
    }
}

// 在AccountManager中直接使用DbContext
public class AccountManager
{
    private readonly IDbContextFactory<AppDbContext> _dbContextFactory;

    public AccountManager(IDbContextFactory<AppDbContext> dbContextFactory)
    {
        _dbContextFactory = dbContextFactory;
    }

    public async Task<decimal> CalculateAccountTotal(int accountId)
    {
        using var dbContext = _dbContextFactory.CreateDbContext();
        var computerCost = await dbContext.GetComputerCostAsync(123);
        
        // 后续计算逻辑...
    }
}

关于细粒度拆分的疑问 #

细粒度拆分本身并不违反编码原则，反而符合单一职责原则——只要拆分的依据是"单一业务职责"，而非随意切割功能。之前的问题可能是拆分方向不对：应该提取服务之间共享的、最小粒度的功能接口，而非盲目拆分服务类。

静态方法导致崩溃的可能原因 #

静态方法如果是无状态且正确释放DbContext，理论上不会直接导致崩溃，但容易引发以下问题：

• 线程安全问题：多个线程同时操作静态资源（如静态变量）导致数据混乱
• 内存泄漏：不小心持有DbContext或其他未释放的资源
• 脱离依赖注入生命周期管理：静态方法无法利用DI的生命周期控制，容易出现资源管理不当

因此，服务层业务逻辑应尽量避免使用静态方法，依托DI的生命周期管理更可靠。

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