【问题标题】:How to swap the data source associated with a Linq query?如何交换与 Linq 查询关联的数据源?
【发布时间】:2013-10-11 06:38:22
【问题描述】:

我在其他答案中阅读了如何在运行时更改 linq 查询的参数。但是是否可以在创建查询之后更改查询浏览的数据源?是否可以为查询提供一个空包装器,在该包装器中可以插入和拔出数据源,而查询不知道?

例如,让我们假设这种情况:

// d1 is a dictionary
var keys =  from entry in d1
            where entry.Value < 5
            select entry.Key;

现在,让我们假设我希望 myQuery 保持不变,而不是修改 d1,但我希望它处理一个全新的字典 d2。

这样做的原因是我想将谁提供查询与谁提供数据源分离。 IE。将字典视为与服务相关联的元数据,将查询视为服务消费者发现哪些服务集与其标准匹配的平均值。我需要对每个服务的元数据应用相同的查询。

我猜我正在(可能是错误地)使用正则表达式进行并行处理:可以编译正则表达式,然后将其应用于任何字符串。我想对查询和字典做同样的事情。

【问题讨论】:

  • 你想做什么?你能展示一些伪代码来解释你所追求的吗?
  • 我不肯定,但听起来您可能正在寻找对象关系映射 (ORM)。
  • LINQ to Objects,或其他形式...?
  • 按要求添加了一些上下文/示例...
  • @manu3d 更新为您展示更标准的选项。

标签: c# linq


【解决方案1】:

LINQ 查询实际上只是一个方法调用。因此,您无法在设置方法后“重新分配”已调用方法的对象。

您可以通过创建一个允许您更改实际枚举的内容的包装类来模拟这一点,即:

public class MutatingSource<T> : IEnumerable<T>
{
     public MutatingSource(IEnumerable<T> originalSource)
     {
         this.Source = originalSource;
     }

     public IEnumerable<T> Source { get; set; }

     IEnumerator IEnumerable.GetEnumerator()
     {
         return this.GetEnumerator();
     }

     public IEnumerator<T> GetEnumerator()
     {
        return Source.GetEnumerator();
     }
}

这将允许您创建查询,然后在事后“改变主意”,即:

var someStrings = new List<string> { "One", "Two", "Three" };

var source = new MutatingSource<string>(someStrings);

// Build the query
var query = source.Where(i => i.Length < 4);

source.Source = new[] {"Foo", "Bar", "Baz", "Uh oh"};

foreach(var item in query)
    Console.WriteLine(item);

这将打印FooBarBaz(来自“已更改”的源项目)。


响应 cmets/edit 进行编辑:

我猜我正在(可能是错误地)使用正则表达式进行并行处理:可以编译正则表达式,然后将其应用于任何字符串。我想对查询和字典做同样的事情。

在这种情况下,查询不像正则表达式。查询被直接翻译成一系列方法调用,这些方法调用只对底层源起作用。因此,您无法更改该来源(没有“查询对象”,只有方法调用的返回值)。

更好的方法是将查询移动到方法中,即:

IEnumerable<TKey> QueryDictionary<TKey,TValue>(IDictionary<TKey,TValue> dictionary)
{
    var keys =  from entry in dictionary
        where entry.Value < 5
        select entry.Key;
    return keys;
}

然后您可以根据需要使用它:

var query1 = QueryDictionary(d1);
var query2 = QueryDictionary(d2);

【讨论】:

  • 嗯。我认为包装示例是该问题的正确答案。在我上面提到的消费者想要找到匹配服务的上下文中,将查询包装到一个方法中会有点问题。我觉得出于安全原因,linq 提供的更具声明性的路径比任意编译的代码更合适。但也许这可以用不可变字典来解决?在这一点上,我想我什至不再需要 linq 查询了。我在这里大声思考。必须再考虑一下。答案的第一部分肯定是有效的。
  • @manu3d 第一部分是实际直接解决问题的唯一尝试。但是,第二种方法仍然可能是更好的方法。即使您的用户正在输入参数,您也可以通过 LINQ 使用用户的参数构建查询(即:添加 where 子句)等。
猜你喜欢
  • 1970-01-01
  • 2021-08-12
  • 1970-01-01
  • 2014-09-03
  • 1970-01-01
  • 1970-01-01
  • 2011-10-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多