EF Core中共享类型实体与查询拦截器的技术挑战与解决方案

在EF Core开发过程中，我们有时会遇到需要根据数据库类型动态调整查询行为的场景。本文将深入探讨一个典型的技术挑战：如何在EF Core中实现跨数据库的全文搜索功能，特别是当使用共享类型实体(SharedTypeEntity)时遇到的查询拦截问题。

背景与需求

在开发支持多数据库(如SQL Server和SQLite)的应用时，全文搜索功能的实现面临一个核心挑战：不同数据库系统对全文搜索的支持方式各不相同。SQL Server提供了内置的全文搜索功能，而SQLite则需要通过FTS(Full-Text Search)虚拟表来实现类似功能。

更复杂的是，SQLite的FTS表在创建时就决定了是否启用词干提取(stemming)功能，这意味着开发者需要为同一个实体维护两个表：一个支持词干提取，一个不支持。

技术实现方案

初始方案：共享类型实体

开发者最初尝试使用EF Core的共享类型实体功能来建模这种情况：

modelBuilder.SharedTypeEntity<TestTableDto>("TestTable");
modelBuilder.SharedTypeEntity<TestTableDto>("TestTable_Stemming");

这种设计允许同一个CLR类型(TestTableDto)映射到数据库中的两个不同表，分别对应是否启用词干提取的搜索场景。

查询拦截与转换

为了实现统一的查询接口，开发者创建了一个自定义的FreeTextSearch方法，并通过IQueryExpressionInterceptor拦截器来根据数据库类型转换查询：

public Expression QueryCompilationStarting(Expression queryExpression, QueryExpressionEventData eventData)
{
    string databaseType = eventData.Context!.Database.GetDatabaseType();
    
    switch(databaseType)
    {
        case DatabaseType.Sqlite:
            return FreeTextSqliteExpressionVisitor.Visit(eventData.Context, queryExpression);
        case DatabaseType.SqlServer:
            return new FreeTextSqlServerExpressionVisitor().Visit(queryExpression);
        default:
            throw new InvalidOperationException("Unsupported database type");
    }
}

对于SQL Server，转换相对简单，可以直接映射到EF.Functions.FreeText或EF.Functions.Contains方法。但对于SQLite，需要根据是否启用词干提取来切换查询的实际表名。

遇到的技术挑战

在SQLite的实现中，开发者遇到了一个关键问题：在查询拦截器的VisitMethodCall方法中，虽然能通过MemberExpression获取到实体类型，但由于使用了共享类型实体，无法直接确定当前查询的是哪个具体的表(TestTable还是TestTable_Stemming)。

这是因为：

1. 共享类型实体意味着同一个CLR类型对应多个EF模型实体
2. 在查询表达式树中，MemberExpression只包含CLR类型信息，不包含EF模型实体的名称
3. 无法通过CLR类型直接获取具体的IEntityType，因为FindEntityType(type)会返回null

解决方案演进

方案一：利用模型名称约定

理论上，可以通过获取原始查询中的实体模型名称(如"TestTable")，然后按照约定(如添加"_Stemming"后缀)来查找对应的词干提取表实体。但在查询拦截器中，难以获取到原始的模型名称信息。

方案二：自定义注解与SQL重写

开发者最终采用的方案是：

1. 放弃共享类型实体，为词干提取和非词干提取场景分别定义不同的CLR类型
2. 通过自定义注解标注词干提取表的名称
3. 在另一个拦截器中捕获生成的SQL并替换表名

这种方案虽然增加了少量的重复代码，但避开了共享类型实体带来的复杂性问题，实现更加直观可靠。

技术启示

1. 共享类型实体的局限性：虽然共享类型实体在某些场景下非常有用，但在需要精确识别具体实体时可能会带来挑战。

2. 查询拦截的层次选择：对于复杂的查询转换，可能需要考虑在更高层次(如SQL生成后)进行干预，而不是局限于表达式树层面。

3. 多数据库支持的权衡：实现跨数据库功能时，有时需要在统一接口的简洁性和实现复杂性之间做出权衡。

这个案例展示了在EF Core中实现高级查询功能时可能遇到的深层次问题，以及如何通过调整架构设计来找到更可行的解决方案。