LINQ(语言集成查询)的优缺点是什么？ 使用 LINQ 的最佳和最坏情况是什么？ 您如何从使用 LINQ 中受益或未受益？ 哪些数据源从 LINQ 中获益最少和最多？
我是 LINQ 的忠实粉丝 - 尽管它需要保持正确的观点，而不是被视为 Elixir 。
优点:
声明式方法使查询更容易理解和更紧凑 可扩展性和表达式树允许对多个源进行大部分一致的查询 甚至进程内查询也可以通过 LINQ to Objects 以外的方式实现 - 例如并行 LINQ 和我自己的 Push LINQ 框架。非常灵活。 对进程内查询非常有用，最容易理解 很高兴能够在字符串等中避免 SQL 默认情况下提供了广泛的运算符，并且可以轻松地为 LINQ to Objects 添加其他运算符 主要为 LINQ 引入的语言功能在其他地方广泛适用(对于 lambdas 来说是的)缺点:
查询表达式的理解不够好，并且被过度使用。通常，简单的方法调用更短更简单。 供应商之间不可避免的不一致——阻抗不匹配仍然存在，这是合理的但需要理解总有一些事情你可以在 SQL 中做但在 LINQ 中不能做 不了解发生了什么，很容易写出非常低效的代码 很难编写 LINQ 提供程序。这很可能是不可避免的，但我们将不胜感激 Microsoft 提供的更多指导。 对于大多数开发者来说，这是一种新的数据访问思维方式，需要时间去理解才能渗透不是专门的 LINQ，而是与之相关的 - 在 C# 中发现扩展方法的方式不够细粒度 一些运算符“缺失”，尤其是 OrderBy 的等价物对于订购以外的事情 - 例如查找具有属性最大值的项 延迟执行和流式传输知之甚少(但有所改进)由于延迟执行和流式传输，调试可能非常棘手 在某些特定情况下，LINQ 可能比手动代码慢得多。您越了解内部工作原理，就越能更好地预测这一点。 (当然，如果性能对您很重要，您应该对它进行适当的测试。)我发现在处理进程内查询时最好。它们很容易预测、理解和扩展。 LINQ to XML 和 Parallel LINQ 等补充技术非常棒。 LINQ to Objects 几乎可以在任何地方使用。
LINQ to SQL 等在它们合适的地方非常好，但它们更难理解并且需要更多的专业知识。它们也仅适用于代码的某些区域。