LINQ的优缺点(语言集成查询)

Question

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

Answer 1

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

优点:

• 声明性方法使查询更容易理解,更紧凑
• 可扩展性和表达式树允许大多数一致地查询多个源
• 甚至进程内查询也可以用LINQ to Objects之外的方式实现 - 例如Parallel 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等在它们合适的地方非常好,但它们更难理解并需要更多的专业知识.它们也仅适用于您代码的某些区域.