.NET6中如何基于BaseService的TRepository限制注入的IDbRepository类型

问题背景 #

现有多数据库场景，每个数据库对应独立DbContext，已实现泛型仓库、上下文及BaseService结构：

现有代码定义 #

泛型仓库及注册：

public class DbRepository<TRepository, TEntity> : IDbRepository<TRepository, TEntity> 
    where TRepository : IContext

// DI注册代码
services.AddScoped(typeof(IDbRepository<,>), typeof(DbRepository<,>));

上下文实现：

public class FirstDbContext : IFirstDbContext
public class SecondDbContext : ISecondDbContext

BaseService定义：

public class BaseService<TRepository> where TRepository : IContext

需求：当子类Service继承BaseService<IFirstDbContext>时，仅允许注入IDbRepository<IFirstDbContext, TEntity>类型的实例，禁止注入其他上下文的仓库（比如IDbRepository<ISecondDbContext, Invoice>）。

实现方案 #

方案1：基类封装仓库获取（编译层面约束，推荐） #

修改BaseService，提供仅能获取当前上下文仓库的方法，强制子类通过基类获取仓库，从编译阶段杜绝非法注入：

public class BaseService<TRepository> where TRepository : IContext
{
    private readonly IServiceProvider _serviceProvider;

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

    // 仅能解析当前TRepository对应的仓库
    protected IDbRepository<TRepository, TEntity> GetRepository<TEntity>()
    {
        return _serviceProvider.GetRequiredService<IDbRepository<TRepository, TEntity>>();
    }
}

子类Service使用方式：

public class UserService : BaseService<IFirstDbContext>
{
    private readonly IDbRepository<IFirstDbContext, User> _userRepo;
    private readonly IDbRepository<IFirstDbContext, Order> _orderRepo;

    public UserService(IServiceProvider serviceProvider) : base(serviceProvider)
    {
        _userRepo = GetRepository<User>();
        _orderRepo = GetRepository<Order>();
        // 尝试获取ISecondDbContext的仓库会直接编译报错
    }
}

方案2：自定义DI注册拦截（运行时约束） #

如果希望保留构造函数注入的形式，可通过自定义DI扩展，在服务注册时检查构造函数参数，拦截非法注入：

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddScopedWithContextRestriction<TService, TImplementation, TContext>(this IServiceCollection services)
        where TService : class
        where TImplementation : class, TService, BaseService<TContext>
        where TContext : IContext
    {
        services.AddScoped<TService, TImplementation>(provider =>
        {
            var ctor = typeof(TImplementation).GetConstructors().First();
            var parameters = new List<object>();

            foreach (var param in ctor.GetParameters())
            {
                // 检查参数是否为当前上下文的仓库类型
                if (param.ParameterType.IsGenericType && 
                    param.ParameterType.GetGenericTypeDefinition() == typeof(IDbRepository<,>) &&
                    param.ParameterType.GetGenericArguments()[0] != typeof(TContext))
                {
                    throw new InvalidOperationException($"Service {typeof(TImplementation).Name} 仅允许注入{typeof(TContext).Name}对应的仓库实例");
                }

                parameters.Add(provider.GetRequiredService(param.ParameterType));
            }

            return (TImplementation)Activator.CreateInstance(typeof(TImplementation), parameters.ToArray());
        });

        return services;
    }
}

注册Service时使用该扩展：

services.AddScopedWithContextRestriction<IUserService, UserService, IFirstDbContext>();

当子类构造函数注入非对应上下文的仓库时，程序启动时会直接抛出异常。

方案3：专属仓库接口隔离（类型层面强约束） #

为每个上下文定义专属的仓库接口，从类型定义上隔离不同上下文的仓库：

1. 定义上下文专属仓库接口：

public interface IFirstDbRepository<TEntity> : IDbRepository<IFirstDbContext, TEntity> { }
public interface ISecondDbRepository<TEntity> : IDbRepository<ISecondDbContext, TEntity> { }

2. 实现对应仓库：

public class FirstDbRepository<TEntity> : DbRepository<IFirstDbContext, TEntity>, IFirstDbRepository<TEntity> { }
public class SecondDbRepository<TEntity> : DbRepository<ISecondDbContext, TEntity>, ISecondDbRepository<TEntity> { }

3. 修改BaseService并约束子类：

public class BaseService<TContext, TRepo> 
    where TContext : IContext
    where TRepo : IDbRepository<TContext, object>
{
    // 基类逻辑
}

public class UserService : BaseService<IFirstDbContext, IFirstDbRepository<object>>
{
    public UserService(
        IFirstDbRepository<User> userRepo, // 允许
        // ISecondDbRepository<Invoice> invoiceRepo // 编译直接报错，类型不匹配
    )
    {
        // ...
    }
}

这种方式彻底从类型层面隔离了不同上下文的仓库，子类无法引用其他上下文的仓库类型。

方案选择 #

• 追求编译时强约束：选方案3，类型隔离最彻底；
• 希望最小改动现有结构：选方案1，基类封装简单高效；
• 需保留构造函数注入且允许运行时检查：选方案2。

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