Question

LINQ（语言集成查询）的优缺点是什么？
使用LINQ的最佳和最差情况是什么？
您如何从使用LINQ中受益或不受益？
哪些数据源从LINQ中获益最少，最多？

Answer 1

我是LINQ的忠实粉丝 - 虽然它需要保持透视，不要被视为银弹。

优点：

声明式方法使查询更容易理解，更紧凑
可扩展性和表达式树允许大多数一致查询多个来源
甚至进程内查询也可以用LINQ to Objects之外的方式实现 - 例如并行LINQ和我自己的Push LINQ框架。非常灵活。
非常对进程内查询很有用，最容易理解
很高兴能够避免字符串中的SQL等
默认情况下提供广泛的运算符，而其他运算符可以轻松添加到LINQ to Objects
主要针对LINQ引入的语言功能在其他地方广泛应用（yay for lambdas）

缺点：

查询表达式不够了解，并且过度使用。通常简单的方法调用更短更简单。
供应商之间不可避免的不一致 - 阻抗不匹配仍然存在，这是合理的，但需要理解
在SQL中总会有一些事情你可以做但在LINQ中却没有。
在不了解正在发生的事情的情况下，编写非常低效的代码很容易。
编写LINQ提供程序很困难。这可能是不可避免的，但微软的更多指导将不胜感激。
这是一种为大多数开发人员考虑数据访问的新方法，需要时间来理解渗透
不是LINQ，而是与它有关 - 在C＃中发现扩展方法的方式不够精细
某些运营商“缺失”，特别是OrderBy等同于订购以外的其他运营商 - 例如查找具有属性最大值的项目
延迟执行和流媒体知之甚少（但正在改进）
由于延迟执行和流式传输，调试可能非常棘手
在某些特定情况下，LINQ可能比手动代码慢得多。你越了解内部运作，你就越能预测到这一点。（当然，如果表现对你很重要，你应该对它进行适当的测试。）

我发现在处理进程内查询时最好。它们易于预测，理解和扩展。 LINQ to XML和Parallel LINQ等辅助技术非常棒。 LINQ to Objects几乎可以在任何地方使用。

LINQ to SQL等在它们合适的地方非常好，但它们更难理解并需要更多的专业知识。它们也仅适用于您代码的某些区域。

Answer 2

我最喜欢的部分：使用它们来简化单元测试。 IEnumerable链也促使我在代码中编写更流畅的接口。

缺点：Lambdas和扩展方法是我的锤子，所有问题都是指甲。

总体而言：为我的C＃编程注入了新的活力。

Answer 3

他们存在一个问题，就是通过延迟执行从try catch块中偷走异常。

例如：

var l = new List<int>() {1, 2, 3};
try
{
    l.Select(x => x / 0);
}
catch
{
    // error
}

l.elementAt(0); // exception occurs here outside of the try catch

第一次遇到它时可能会很棘手，尤其是调试器会指向try-catch中的代码。

否则我发现它们非常有用且节省时间。

Answer 4

我主要使用LINQ来处理对象的收集。 LINQ与对象集合完美配合，在大多数情况下不再需要谓词函数。

我之前尝试过使用LINQ to SQL，但发现它功能不足且笨拙。特别是我无法使用SQL Database类设计器。也许它确实在数据库上提供了intellisense，但是当你有SQL时谁需要它？

让我告诉你，了解更多有关LINQ的信息肯定是一个好主意，因为未来的应用程序应该只会增加。

Answer 5

临：

LINQ to SQL允许RAD非常好地使用数据库
查询多个数据源很容易
LINQ to SharePoint，LINQ to Active Directory，LINQ to TFS，LINQ to Umbraco，（并且列表继续）

缺点：

与任何新技术一样，太多人不理解但仍然使用它

@Jon Skeet - 另一个伟大的回应，你偷了每个人的雷声：P。我完全同意写一个提供者的难度，我现在正处于这个过程中！你熟悉Bart De Smet吗？他有很多很好的例子。

LINQ的优缺点（语言集成查询）

5 个答案: