依赖 LinqToObjects 的自定义 IQueryProvider

Question

我编写了一个自定义 IQueryProvider 类，该类接受一个表达式并针对 SQL 数据库对其进行分析（我知道我可以使用 Linq2Sql，但我需要进行一些修改和调整，不幸的是，Linq2Sql 不适合）。该类将识别并使用标记的属性（使用属性）执行某些操作，但我希望能够将表达式传递给 LinqToObject 提供程序并允许它在之后过滤结果。

例如，假设我有以下 linq 表达式：

var parents=Context.Parents
    .Where(parent=>parent.Name.Contains("T") && parent.Age>18);

Parents 类是一个自定义类，实现了 IQueryProvider 和 IQueryable 接口，但是只有 Age 属性被标记为检索，所以 Age 属性会被处理，但是 Name 属性因为没有标记而被忽略。处理完 Age 属性后，我想将整个表达式传递给 LinqToObjects 进行处理和过滤，但我不知道如何进行。

注意它不需要删除表达式的 Age 子句，因为即使在我处理它之后结果也是一样的，所以我总是能够将整个表达式发送到 LinqToObjects。

我已经尝试了以下代码，但似乎不起作用：

IEnumerator IEnumerable.GetEnumerator() {       
    if(this.expression != null && !this.isEnumerating) {
        this.isEnumerating = true;
        var queryable=this.ToList().AsQueryable();
        var query = queryable.Provider.CreateQuery(this.expression);
        return query.GetEnumerator();
    }
    return this;
}

this.isEnumering 只是一个布尔标志设置以防止递归。

this.expression 包含以下内容：

{value(namespace.Parents`1[namespace.Child]).Where(parent => ((parent.Name.EndsWith("T") AndAlso parent.Name.StartsWith("M")) AndAlso (parent.Test > 0)))}

当我逐步执行代码时，尽管将结果转换为列表，它仍然使用我的自定义类进行查询。所以我想，因为类 Parent 在表达式的开头，它仍然将查询路由回我的提供者，所以我尝试将 this.expression 设置为方法调用的 Argument[1] 所以它是这样的：

{parent => ((parent.Name.EndsWith("T") AndAlso parent.Name.StartsWith("M")) AndAlso (parent.Test > 0))}

对我来说，哪个看起来更像它，但是，每当我将它传递给 CreateQuery 函数时，我都会收到此错误“参数表达式无效”。

表达式的节点类型现在是“引用”而不是“调用”，并且该方法为空。我怀疑我只需要以某种方式使这个表达式成为调用表达式，它就会起作用，但我不确定如何。

请记住，这个表达式是一个 where 子句，但它可以是任何类型的表达式，我不希望在将它传递给 List 查询提供程序之前尝试分析该表达式以查看它是什么类型。

也许有一种方法可以将原始表达式的 Parent 类剥离或替换为列表提供程序类，但仍然保持一种状态，无论表达式的类型如何，它都可以作为表达式传入列表提供程序？

对此的任何帮助将不胜感激！

Answer 1

你们离得太近了！

我的目标是避免必须“复制”完整的令人麻木的复杂 SQL 到对象表达式功能集。你让我走上了正轨（谢谢！）以下是如何在自定义 IQueryable 中搭载 SQL 到对象：

public IEnumerator<T> GetEnumerator() {

    // For my case (a custom object-oriented database engine) I still 
    // have an IQueryProvider which builds a "subset" of objects each populated 
    // with only "required" fields, as extracted from the expression. IDs, 
    // dates, particular strings, what have you. This is "cheap" because it 
    // has an indexing system as well.

    var en = ((IEnumerable<T>)this.provider.Execute(this.expression));

    // Copy your internal objects into a list.

    var ar = new List<T>(en);
    var queryable = ar.AsQueryable<T>();

    // This is where we went wrong:
    // queryable.Provider.CreateQuery(this.expression);
    // We can't re-reference the original expression because it will loop 
    // right back on our custom IQueryable<>. Instead, swap out the first 
    // argument with the List's queryable:

    var mc = (MethodCallExpression)this.expression;
    var exp = Expression.Call(mc.Method, 
                    Expression.Constant(queryable), 
                    mc.Arguments[1]);


    // Now the CLR can do all of the heavy lifting
    var query = queryable.Provider.CreateQuery<T>(exp);
    return query.GetEnumerator();
}

不敢相信我花了 3 天的时间才弄清楚如何避免在 LINQ 到对象查询上重新发明轮子。