- LINQ(语言集成查询(的优缺点是什么？
- 使用 LINQ 的最佳和最差情况是什么？
- 您对使用 LINQ 有什么好处或没有好处？
- 哪些数据源从 LINQ 中受益最少，但受益最大？
我是 LINQ 的忠实粉丝 - 尽管它需要保持透视，而不是被视为银弹。
优点：
- 声明式方法使查询更易于理解和更紧凑
- 扩展性和表达式树允许对多个源进行基本一致的查询
- 即使是进程内查询也可以用 LINQ to Object 以外的方式实现 - 例如并行 LINQ 和我自己的 Push LINQ 框架。非常灵活。
- 对于进程内查询非常有用，最容易理解
- 很高兴能够避免字符串中的SQL等
- 默认情况下提供多种运算符，并且可以轻松地为 LINQ to Objects 添加其他运算符
- 主要为 LINQ 引入的语言功能在其他地方广泛适用(是 lambda(
缺点：
- 查询表达式不够好理解，并且被过度使用。通常，简单的方法调用更短、更简单。
- 提供商之间不可避免的不一致 - 阻抗不匹配仍然存在，这是合理的，但需要了解
- 总有一些事情可以在 SQL 中执行，但在 LINQ 中则不行 。
- 如果不了解发生了什么，很容易编写非常低效的代码
- 编写 LINQ 提供程序很难。这很可能是不可避免的，但Microsoft的更多指导将不胜感激。
- 对于大多数开发人员来说，这是一种思考数据访问的新方式，需要时间来理解才能渗透。
- 不是特定的 LINQ，而是与之相关 - 在 C# 中发现扩展方法的方式不够精细
- 一些运算符"缺失"，特别是对于订购以外的事物的等价物
OrderBy- 例如，查找具有属性最大值
的项目 - 延迟执行和流式处理知之甚少(但正在改进(
- 由于延迟执行和流式处理，调试可能非常棘手
- 在某些特定情况下，LINQ 可能比手动代码慢得多。你越了解内部运作，你就越能预测这一点。(当然，如果性能对您很重要，您应该对其进行适当的测试。
我发现在处理进程内查询时最好。它们易于预测、理解和扩展。像 LINQ to XML 和 Parallel LINQ 这样的补充技术非常棒。LINQ to Objects 几乎可以在任何地方使用。
LINQ to SQL 等在合适的地方真的很好，但它们更难理解并且需要更多的专业知识。它们也仅适用于代码的某些区域。
我最喜欢的部分：使用它们来简化编写单元测试。 此外，IE无数链也敦促我在代码中编写更流畅的接口。
缺点： Lambda 和扩展方法是我的锤子，所有问题都是钉子。
总的来说：为我用 C# 编程注入了新的活力。
它们存在
通过延迟执行将异常从 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 中的代码时。
否则，我发现它们非常有用且非常节省时间。
Pro：
- LINQ to SQL允许RAD与数据库非常好
- 轻松查询多个数据源 LINQ to
- SharePoint，LINQ to Active Directory，LINQ to TFS，LINQ to Umbraco，(列表还在继续(
缺点：
- 像任何新技术一样，太多人不理解它，但仍然使用它
@Jon 双向飞碟 - 另一个很棒的回应，你偷走了每个人的雷霆:P。我完全同意编写提供程序有多难，我现在正在编写它！你熟悉巴特·德·斯梅特吗？他有很多这样做的好例子。
我使用 LINQ 主要用于处理对象的集合。LINQ 可以很好地与对象集合配合使用，在大多数情况下无需使用谓词函数。
不久前，我尝试使用 LINQ to SQL，但发现它功能不足且笨拙。特别是，我无法让自己使用 SQL 数据库类设计器。也许它确实在数据库上提供了智能感，但是当你有SQL时，谁需要它呢？
不过，让我告诉你，了解有关 LINQ 的更多信息当然是一个好主意，因为将来的应用程序只会增加。