LINQ to Everything是一个很好的抽象？

Question

新的LINQ提供商数量激增。它非常令人惊讶，并且lambda表达式，匿名类型和泛型的优雅组合以及顶部的一些语法糖使其易于阅读。现在，从SQL到Amazon到streaming sensor data到parallel processing等网络服务，所有内容都已LINQed。似乎有人正在创建一个IQueryable <T＆gt;除了这些数据源之外，所有数据源都可以具有完全不同的性能，延迟，可用性和可靠性特征

它给了我一点停顿，LINQ使这些性能细节对开发人员透明。 LINQ是一个可靠的通用抽象或RAD工具还是两者兼而有之？

Answer 1

对我来说，LINQ只是一种使代码更具可读性的方法，因此更易于维护。 LINQ只是采用标准方法并将它们集成到语言中（因此名称 - 语言集成查询）。

它只不过是普通接口和方法的语法元素 - 这里没有“魔法”，LINQ-to-something真的应该（IMO）被视为任何其他第三方API - 你需要了解成本/使用它的好处就像任何其他技术一样。

话虽如此，它是一个非常好的语法助手 - 它使代码更清晰，更简单，更易于维护，并且我相信这是真正的优势所在。

Answer 2

我认为这与RDBMS中的多个存储引擎的模型类似接受SQL的通用（-ish）语言，在它的设计中...但是具有集成的额外好处应用程序语言语义。当然很好！

我没有那么多地使用它，但是当性能和抽象层不能对开发过程产生负面影响（并且相信标准和模型不会发生巨大变化）时，它看起来很明智和清晰。 / p>

它只是一个可以满足您需求的接口和实现，就像所有接口，抽象，库和实现一样，它适合吗？... 它是完全相同的答案< /强>

Answer 3

我想 - 不。

LINQ只是一种方便的语法，但不是常用的RAD工具。在具有复杂逻辑的大项目中，我注意到开发人员在LINQ中执行了更多错误，如果他们以.NET 2.0方式编写相同的内容，他们可以执行相同的指令。代码生成得更快，更小，但更难找到错误。有时从第一眼看起来并不明显，查询的集合在什么时候从IQueryable转变为IEnumerable ...我会说LINQ需要更多熟练和有纪律的开发人员。

类似SQL的语法对于函数式编程也是可以的，但它是面向对象思维的一个回避。有时当你看到2个非常相似的LINQ查询时，它们看起来像是复制粘贴代码，但并不总是任何重构都是可能的（或者只有牺牲一些性能才有可能）。

我听说MS不打算进一步开发LINQ to SQL，并且会优先考虑实体。 Is the ADO.NET Team Abandoning LINQ to SQL?对于我们来说，LINQ不是每个人的灵丹妙药，这不是一个信号吗？

如果您正在考虑构建一个“某种东西”的连接器，您可以在没有LINQ的情况下构建它，如果您愿意，可以提供LINQ作为其附加的可选包装，如LINQ to Entities 。因此，您的客户将决定是否使用LINQ，具体取决于他们的需求，所需的性能等。

P.S。 .NET 4.0将带有动态性，我希望每个人都会开始将它们用作LINQ ......而不考虑代码的简单性，质量和性能可能会受到影响。