对LINQ上瘾[关闭]

另一项观察;如果你不使用类型化数据集,你可能还想知道 Field<> 扩展方法:

    var customerOrderIds = table.Rows.Cast<DataRow>()
       .Where(x => x.Field<string>("CUSTOMER_ID") == customerId)
       .Select(x => x.Field<string>("CUSTOMER_ORDER_ID"))
       .Distinct();

或者使用查询语法:

   var customerOrderIds = (
        from row in table.Rows.Cast<DataRow>()
        where row.Field<string>("CUSTOMER_ID") == customerId
        select row.Field<string>("CUSTOMER_ORDER_ID")
     ).Distinct();

我并不是说这是好是坏,只是另一个可行的选择。

(事实上,我不使用 DataTable 非常喜欢,所以YMMV)

在我看来,这很好——尽管我会尝试使用强类型数据集,这会使LINQ查询看起来更令人愉快。

但是,是的,LINQ是一件非常好的事情,与进程外的LINQ提供程序相比,LINQ to Objects(以及XML和数据集的相关技术)具有惊人的可预测性。(少了 性感的 比LINQ to SQL更有效,但在IMO中应用更广泛。)

查询看起来很好。

我想指出两件小事。

无循环

系统。林克。枚举方法对IEnumerable(T)契约进行操作,这几乎总是意味着循环-O(N)解决方案。这有两个含义:

• 更喜欢Any()而不是Count()> 0 .Any()是O(1)。Count()为O(N)。
• 加入。..所有连接都是嵌套循环O(M*N)。

.演员阵容

.Cast非常适合DataTable。行(所有这些对象都是行,所以强制转换总是成功的)。对于异构集合,请注意。OfType()-过滤掉任何无法转换的项目。

最后,请注意,查询只有在枚举后才会执行!您可以通过foreach、ToList、ToArray、First、Single等强制枚举。

就我个人而言,由于数据表本身没有能力进行选择,我会说它并没有那么糟糕。

不过,我可能会问,是否有办法最终使用对象而不是数据表,因为我认为这对未来的开发人员来说会更容易理解。

你一点也没被冲昏头脑。在LINQ to DataSets上发布了一些实际作品。拥有如此清晰、声明性的对象查询可以使代码更容易维护。但你必须记住,在过滤数据时,所有数据都已经被撤回。您可能需要考虑将过滤添加到DataSet查询的SQL中。

LINQ只是为您编写“循环/临时变量”代码。LINQ可以帮助您更快地编写代码(并且更具可读性)。

你的代码很好。

join(使用join关键字,但不使用from关键字)使用Dictionary进行匹配,因此 O(M+N) .

以下是一组,但不是:

from x in Xs
from y in Ys
    .Where(o => o == x)
select new
{
    x,
    y
}

哪个是 O(M*N) .