EntityFramework Core 中 IEntityTypeConfiguration 的依赖注入支持探讨

背景

在 EntityFramework Core 的开发实践中，我们经常会遇到需要为不同实体配置不同模型的情况。EF Core 提供了 IEntityTypeConfiguration<T> 接口来帮助我们更好地组织模型配置代码，同时通过 ApplyConfigurationsFromAssembly 方法可以自动扫描并应用程序集中的所有配置类。

然而，在实际开发中，特别是多租户系统中，我们经常需要在模型配置中使用一些运行时信息（如租户ID）。这时就遇到了一个限制：ApplyConfigurationsFromAssembly 方法内部使用 Activator.CreateInstance 创建配置类实例，不支持依赖注入。

问题分析

在多租户系统中，常见的场景包括：

1. 需要根据租户ID设置全局查询过滤器
2. 需要根据租户信息配置不同的表名或架构
3. 需要根据租户特性启用/禁用某些特性

理想情况下，我们希望能够在配置类中注入这些依赖项，就像在 DbContext 中一样：

public class TenantEntityConfiguration : IEntityTypeConfiguration<Product>
{
    private readonly ITenantContext _tenantContext;
    
    public TenantEntityConfiguration(ITenantContext tenantContext)
    {
        _tenantContext = tenantContext;
    }
    
    public void Configure(EntityTypeBuilder<Product> builder)
    {
        builder.HasQueryFilter(p => p.TenantId == _tenantContext.TenantId);
    }
}

当前解决方案

目前 EF Core 团队决定不扩展 ApplyConfigurationsFromAssembly 的功能，认为这只是一种语法糖，开发者可以根据自己的需求实现更适合的模式。

现有替代方案

1. 手动注册配置类： 直接实例化配置类并传递依赖项：

   modelBuilder.ApplyConfiguration(new TenantEntityConfiguration(tenantContext));
   

2. 自定义扫描实现： 创建自己的扩展方法，使用 ActivatorUtilities 和 IServiceProvider 来构造配置实例。

3. 利用闭包特性： EF Core 有一个特殊处理：当查询过滤器表达式中引用了与当前上下文类型匹配的闭包时，会在运行时替换为当前上下文实例：

   private sealed class EntityConfiguration : IEntityTypeConfiguration<Customer>
   {
       private readonly SomeDbContext _context; // 运行时会被替换
       
       public void Configure(EntityTypeBuilder<Customer> builder)
       {
           builder.HasQueryFilter(d => d.TenantId == _context.TenantId);
       }
   }
   

技术深入

表达式树处理机制

EF Core 在处理查询过滤器时，不会直接执行表达式，而是将其存储为表达式树。在查询执行时：

1. 将过滤器表达式树合并到查询表达式树中
2. 在表达式树转换过程中，遇到闭包引用时：
   • 如果是普通值类型，直接取值
   • 如果类型匹配当前上下文类型，则替换为当前上下文实例

这种机制虽然强大，但确实有些"魔法"性质，不够直观。

设计考量

EF Core 团队在设计上的考虑包括：

1. 性能：ApplyConfigurationsFromAssembly 需要快速执行，依赖注入会增加开销
2. 简单性：保持基础功能的简单性，复杂需求由开发者自行扩展
3. 一致性：模型构建阶段和查询执行阶段使用不同的上下文实例

最佳实践建议

基于以上分析，对于需要在模型配置中使用依赖项的场景，建议：

1. 简单场景：使用闭包特性，但需添加充分注释说明
2. 中等复杂度：手动注册配置类，保持明确性
3. 复杂系统：实现自定义的配置扫描机制，完全控制实例创建过程

对于多租户系统，一个健壮的实现可能包括：

// 扩展方法
public static void ApplyTenantConfigurations(
    this ModelBuilder modelBuilder, 
    Assembly assembly, 
    IServiceProvider serviceProvider)
{
    var configurationTypes = assembly.GetTypes()
        .Where(t => t.IsClass 
            && !t.IsAbstract
            && t.GetInterfaces().Any(i => 
                i.IsGenericType 
                && i.GetGenericTypeDefinition() == typeof(IEntityTypeConfiguration<>)));
    
    foreach (var type in configurationTypes)
    {
        var configuration = ActivatorUtilities.CreateInstance(serviceProvider, type);
        var applyMethod = modelBuilder.GetType()
            .GetMethod("ApplyConfiguration")
            .MakeGenericMethod(type.GetInterfaces()[0].GetGenericArguments()[0]);
        
        applyMethod.Invoke(modelBuilder, new[] { configuration });
    }
}

未来展望

虽然当前 EF Core 团队决定不改变现有机制，但开发者社区可以：

1. 创建并共享高质量的扩展库
2. 推动更明确的上下文引用API设计
3. 探索模型配置与依赖注入更优雅的集成方式

理解这些底层机制不仅能帮助我们解决当前问题，也能更好地预见和适应框架的未来发展。