我刚刚查看了其中一个命名模式为“something-Linq”的库，希望获得更多关于如何以优雅的方式构建表达式树的知识——结果很失望。因为我只能找到扩展 IEnumerable 的方法——当然是使用“普通”C# 代码。
现在我有这个问题:IEnumerable 的非表达式扩展真的证明库的名称中包含“Linq”吗？或者作者只是在大肆宣传，试图为他的 IEnumerable 扩展库获得更多下载，而当在库名称中看到“Linq”时，我期待 IQueryable 和表达式是正确的？
编辑:
我认为 Linq-to-... 和 something-Linq 库之间存在差异。恕我直言，Linq-to-... 是 linq 提供程序库，something-Linq 是 linq 扩展。我认为 Linq 提供程序库可能会选择是否在其结果中公开 IQueryable 或 IEnumerable - Linq 扩展没有该选择。就我而言，他们必须能够使用两种类型的提供程序库。这对我来说意味着所有 linq 扩展都必须同时提供可查询和可枚举扩展。
编辑 2:
Jon 和我在他回答的评论中进行了非常热烈的讨论。我自愿创建了一篇博文，希望能澄清一些事情: Mapping the uncharted waters of LINQ
编辑 3:
对于任何对讨论感兴趣的人 - 我真的鼓励你去我的博客文章。跳过帖子本身，因为它太可怕了 - 直接进入 Jon 的讨论和解释。
最佳答案
LINQ 对我来说并不意味着表达式树。它意味着以 LINQ 的一般风格进行数据访问。 LINQ to Objects 中没有任何表达式树，但仍然绝对是 LINQ IMO。
LINQ to XML 有点似是而非 - 它实际上只是一个公开 IEnumerable<T> 的 XML API以各种方式，既可以作为输入也可以作为输出。这意味着它与 LINQ to Objects 一起工作得很好，但它本身没有实现任何标准运算符。但是，您通常将它与 LINQ to Objects 一起使用，结果是“类似 LINQ”的代码，所以我想这还不错。
我当然不介意非表达式扩展被称为 LINQ-to-whatever - 事实上，考虑到我的 MoreLINQ，这种立场是虚伪的和 Push LINQ项目。
对我来说有两个主要问题:
- API 是否与数据访问和处理有关？
- 它是否试图使访问/处理流畅，理想情况下(但不一定)符合查询表达式模式，以启用 VB9 和 C#3 的语言功能来帮助编写可读代码？
关于c# - 什么时候图书馆应该被称为 "Linq-something"或 "something-Linq"？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/629411/