适配共享领域实体与仓储/工作单元模式的依赖注入模式选型

针对多应用共享领域实体、仓储需动态切换不同DbContext的问题，以下几种实用方案可以解决：

方案1：泛型仓储+基类DbContext约束（最简洁的独立应用场景方案） #

如果Forms和Complaints是独立部署的应用，这种方案无需动态切换逻辑，直接通过DI绑定对应上下文：

1. 定义基类DbContext
   把共享实体的配置统一放在基类中，避免重复代码：

public abstract class BaseSharedDbContext : DbContext
{
    public DbSet<Account> Accounts { get; set; }

    protected BaseSharedDbContext(DbContextOptions options) : base(options) { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // 在这里统一配置Account实体的Fluent API规则
        modelBuilder.Entity<Account>(entity =>
        {
            entity.HasKey(a => a.Id);
            entity.Property(a => a.Email).IsRequired().HasMaxLength(256);
            // 其他通用配置
        });
    }
}

// 各自应用的DbContext继承基类
public class FormsDbContext : BaseSharedDbContext
{
    public FormsDbContext(DbContextOptions<FormsDbContext> options) : base(options) { }
    // Forms应用专属的DbSet
}

public class ComplaintsDbContext : BaseSharedDbContext
{
    public ComplaintsDbContext(DbContextOptions<ComplaintsDbContext> options) : base(options) { }
    // Complaints应用专属的DbSet
}

2. 实现泛型仓储
   让仓储绑定特定的DbContext类型：

public class AccountRepository<TContext> : IAccountRepository 
    where TContext : BaseSharedDbContext
{
    private readonly TContext _dbContext;

    public AccountRepository(TContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<Account> GetByIdAsync(Guid id)
    {
        return await _dbContext.Accounts.FindAsync(id);
    }

    // 其他仓储方法（如Add、Update等）直接使用_dbContext操作即可
}

3. 在各自应用中注册DI
   每个应用只注册自己的DbContext和对应仓储：

// Forms应用的Program.cs
builder.Services.AddDbContext<FormsDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("FormsDb")));
builder.Services.AddScoped<IAccountRepository, AccountRepository<FormsDbContext>>();

// Complaints应用的Program.cs
builder.Services.AddDbContext<ComplaintsDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("ComplaintsDb")));
builder.Services.AddScoped<IAccountRepository, AccountRepository<ComplaintsDbContext>>();

这样在各自应用中，注入IAccountRepository时会自动拿到绑定自身DbContext的实现，完全无需切换逻辑。

方案2：命名服务+工厂模式（适合单应用多场景切换） #

如果需要在同一个服务中动态切换Forms/Complaints的上下文（比如一个后台任务处理两个应用的数据），可以用命名服务+工厂实现：

1. 注册命名DbContext

// Program.cs中注册两个命名的DbContext
builder.Services.AddDbContext<FormsDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("FormsDb")));
builder.Services.AddDbContext<ComplaintsDbContext>(options => 
    options.UseSqlServer(builder.Configuration.GetConnectionString("ComplaintsDb")));

// 注册带键的DbContext服务
builder.Services.AddKeyedScoped<DbContext, FormsDbContext>("Forms");
builder.Services.AddKeyedScoped<DbContext, ComplaintsDbContext>("Complaints");

2. 创建仓储工厂

public interface IAccountRepositoryFactory
{
    IAccountRepository Create(string appIdentifier);
}

public class AccountRepositoryFactory : IAccountRepositoryFactory
{
    private readonly IServiceProvider _serviceProvider;

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

    public IAccountRepository Create(string appIdentifier)
    {
        var dbContext = _serviceProvider.GetRequiredKeyedService<DbContext>(appIdentifier);
        return new AccountRepository(dbContext);
    }
}

// 注册工厂
builder.Services.AddScoped<IAccountRepositoryFactory, AccountRepositoryFactory>();

3. 使用时动态获取仓储

public class CrossAppDataService
{
    private readonly IAccountRepositoryFactory _repoFactory;

    public CrossAppDataService(IAccountRepositoryFactory repoFactory)
    {
        _repoFactory = repoFactory;
    }

    public async Task SyncAccountsBetweenApps()
    {
        // 获取Forms应用的仓储
        var formsRepo = _repoFactory.Create("Forms");
        var formsAccounts = await formsRepo.GetAllAsync();

        // 获取Complaints应用的仓储
        var complaintsRepo = _repoFactory.Create("Complaints");
        foreach(var account in formsAccounts)
        {
            await complaintsRepo.AddIfNotExistsAsync(account);
        }
    }
}

方案3：上下文解析器（灵活适配多场景） #

如果需要更细粒度的上下文切换控制，可以实现一个解析器：

public interface IDbContextResolver
{
    DbContext GetContextForApp(string appId);
}

public class DbContextResolver : IDbContextResolver
{
    private readonly IServiceProvider _serviceProvider;

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

    public DbContext GetContextForApp(string appId)
    {
        return appId switch
        {
            "Forms" => _serviceProvider.GetRequiredService<FormsDbContext>(),
            "Complaints" => _serviceProvider.GetRequiredService<ComplaintsDbContext>(),
            _ => throw new ArgumentException($"Unsupported app identifier: {appId}")
        };
    }
}

// 注册解析器
builder.Services.AddScoped<IDbContextResolver, DbContextResolver>();

在仓储中可以直接注入解析器，在方法中动态获取上下文：

public class AccountRepository : IAccountRepository
{
    private readonly IDbContextResolver _resolver;

    public AccountRepository(IDbContextResolver resolver)
    {
        _resolver = resolver;
    }

    public async Task<Account> GetByIdAsync(Guid id, string appId)
    {
        var dbContext = _resolver.GetContextForApp(appId);
        return await dbContext.Set<Account>().FindAsync(id);
    }
}

关键注意事项 #

• 共享实体的配置必须统一，建议放在基类DbContext的OnModelCreating中，避免不同上下文出现不一致的映射规则。
• 如果使用动态切换方案，要确保应用标识的来源可靠（比如配置文件、请求头、环境变量），避免错误切换导致数据访问异常。
• 泛型方案是独立部署应用的最优解，无需额外切换逻辑，符合DI的单一职责原则。

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