Linq to Everything是一个很好的抽象吗?

对我来说,LINQ只是一种使代码更可读、更可维护的方法。Linq只采用标准方法并将它们集成到语言中(因此称为语言集成查询)。

它只是围绕正常接口和方法的一个语法元素-这里没有“魔力”,而linq to something(imo)应该被视为任何其他第三方API-您需要像其他技术一样理解使用它的成本/好处。

这就是说,它是一个非常好的语法助手——它为使代码更干净、更简单和更易于维护做了很多工作,我相信这就是它真正的优势所在。

我认为这是 类似的 对于RDBMS中多个存储引擎的模型,采用了一种通用的(ish)SQL语言,在其设计中…但是,集成到应用程序语言语义中会带来额外的好处。当然很好!

我没有使用过那么多,但是当性能和抽象层不足以对开发过程产生负面影响时(并且相信标准和模型不会发生剧烈变化),它看起来是明智和清晰的。

它只是一个接口和实现,可以满足您的需求 像所有接口、抽象、库和实现一样,它是否适合?… 答案都一样 .

我想没有。

LINQ只是一个方便的语法,但不是一个通用的RAD工具。在具有复杂逻辑的大型项目中,我注意到开发人员在LINQ中执行的错误更多,如果他们以.NET 2.0方式编写相同的内容,他们可以按照相同的指令执行这些错误。代码生成更快,更小,但更难发现错误。有时,从第一眼看,这并不明显,在什么时候查询的集合从iqueryable变成了IEnumerable…我会说,Linq需要更熟练和训练有素的开发人员。

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

我听说MS不会进一步开发Linq-to-SQL,并且会把更多的优先权放在实体上。 Is the ADO.NET Team Abandoning LINQ to SQL? 这难道不是我们的一个信号,林肯不是一个万能的每个人?

如果你想建立一个连接到 某物 “,您可以在不使用LINQ的情况下构建它,如果愿意,还可以提供LINQ作为围绕它的附加可选包装器,如LINQ to Entities。因此,您的客户将根据他们的需求、所需的性能等决定是否使用LINQ。

附笔 .NET 4.0将随Dynamics一起提供,我希望每个人都将开始使用它们作为LINQ…不考虑代码的简单性、质量和性能。