不使用 LINQ 的原因 [关闭]答案

【问题标题】：Reason not to use LINQ [closed]不使用 LINQ 的原因 [关闭]
【发布时间】：2009-10-16 07:46:18
【问题描述】：

有什么好的理由不在我的项目中使用 LINQ？我们使用 .Net 3.5 和 VSTO 3.0。

【问题讨论】：

请看this topic：它可能会帮助你得到答案。
让选民结束这个问题：恕我直言，这是一个有效的问题，为什么要关闭它？
这只是很有争议的，因为 LINQ 的使用主要是个人喜好，就像其他几个主题一样。为什么要使用 Windows？为什么使用 C#？为什么使用 Java？为什么要使用PC？这是一个很容易引起热议的话题，毫无价值。
好吧，很遗憾 crauscher 使用了“不这样做的理由”（我将其编辑为不太主观的“缺点”，但他不喜欢这样：P）但下面有一个有效的题。我会将其与“使用 ORM / Lucene / Remoting 有什么缺点”等问题进行比较。
Linq（语言集成查询，iirc）只是一些扩展方法（恰好位于 Linq 命名空间中）的更好的语法（from T in X select T）。您的问题是指语法与扩展方法还是整个 Linq 包（包括匿名类型）？

标签： c# .net linq vsto

【解决方案1】：

就我个人而言，我不明白你为什么不想使用它，它使代码更具可读性。

话虽如此，LINQ 在某些情况下有时会损害性能，这只是我不使用它的原因。

【讨论】：

@m.edmondson 你的文章是一个 lambda 表达式而不是 LINQ。我同意你的观点，尽管尝试保持可读性总是好的，但是，如果我有可读的代码并且需要 5 秒，而代码需要 0.5 秒并且不那么可读，我会选择使用更高效的代码。您可以通过放入函数或注释来使复杂的代码具有可读性。
谢谢你，我已经修改了我的文章，更新了你关于 lambda/LINQ 的观点
@m.edmondson 我想我要说的一件事是虽然它们不可互换，但它们彼此是等价的（它们都将编译成完全相同的 IL）。这仅取决于您喜欢如何编写查询，有些使用 LINQ 更容易阅读，有些使用 Lambda 更容易（或更简洁）。
没错，我一直在阅读John Skeet's article about this
我是个怪人，但我发现阅读非 linq 表达式更容易

【解决方案2】：

其他答案暗示了这一点，但这里是明确的：

术语“LINQ”可以指代L语言IN集成Query的整体技术集。这些技术允许将 LINQ 查询转换为表达式树。该树可以稍后由“LINQ Provider”执行。

LINQ 提供程序查看表达式树并将其转换为例如 SQL 语句或 XML DOM 导航或通过对象图导航。这些提供程序的名称有“LINQ to SQL”、“LINQ to Entities”、“LINQ to Objects”等。

可能有理由不使用特定的提供者。

许多单独的 LINQ 提供程序都带有额外的工具（有些人会说，“包袱”）。此工具有助于提供有关 LINQ 的一些最常见的“优缺点”。

特别是，LINQ to SQL 提供了到数据库模式的直接、一对一映射。每个 LINQ 类对应一个数据库表。如果数据库的结构发生变化，那么代码也会发生变化。使用视图可以在一定程度上缓解这种情况。

我相信 LINQ to SQL 仅限于 Microsoft SQL Server。此外，Microsoft 已表示 LINQ to SQL 不会成为未来的优先投资。

LINQ to Entities 是 ADO.NET 实体框架 (EF) 的一部分。 EF 提供了在更抽象的概念级别对您的实体进行建模。例如，您可能有一个 Person 实体，它从具有一对一映射的两个表中获取数据。访问此实体的代码不需要关心表在数据库中是如何划分的。

我相信 LINQ to Entities 旨在与许多 ADO.NET 提供程序一起工作，而不仅仅是 SQL Server。此外，微软表示将在这方面进行投资。

在 LINQ 到“某些数据库”的这两种情况下，几乎总是有经验的 SQL 开发人员和/或 DBA 可以编写比 LINQ 生成的查询更好的查询。如果性能是最高要求，我相信 LINQ to Entities 可以将存储过程映射到实体上的方法。

这些 LINQ 提供程序的最大好处是，当您在性能不是首要任务的环境中工作时，您不需要经验丰富的 SQL 开发人员或 DBA。这让他们可以腾出时间来优化实际上需要他们专业知识的查询。

不直接使用它们的另一个原因是，如果您出于安全考虑阻止您的用户对数据库表具有 SELECT 权限。在这种情况下，请使用视图或存储过程。

【讨论】：

对某人应该查看的问题的最接近的解释和答案。正如它所暗示的“语言集成查询”。 +1

【解决方案3】：

是的，有原因。我将谈谈我在为 RDBMS 使用各种 LINQ 提供程序时遇到的一些困难。

LINQ 在大多数情况下都能很好地工作，但是当您想要构建复杂的查询（例如在报告应用程序中）时，它的静态类型特性就成了一个劣势。例如，很难进行有条件的 JOIN 或有条件的 GROUP BY，因为结果类型会发生变化，即使最终您想要投影相同的字段。左连接也很难。如果您真的很喜欢动态查询，那么 SQL 和 ESQL 是更好的选择。

此外，同一个 LINQ 查询可能（并且通常是）不同的解释，具体取决于提供程序，这可能会在切换提供程序时导致意外结果。

关于 SQL 函数，并非您需要的所有函数都映射到 CLR 方法，也不是所有提供程序都提供映射函数的扩展机制。

最后，性能问题。将表达式树转换为存储查询可能会很昂贵，有时最终结果并不是最好的查询。最优雅的源代码并不总是最好的运行时代码。

【讨论】：

【解决方案4】：

唯一的原因是如果您有一个性能非常关键的应用程序，因为 LINQ to Objects 查询的性能通常比 for 循环差。当您可以使用 PLINQ 的并行处理功能时，这将在 .Net 4.0 中改变。

无论如何，如果您有这样一个对性能至关重要的应用程序，那么您可能无论如何都不应该使用托管环境。在 99% 的情况下，LINQ 将使您的代码更易读、更优雅。它的延迟执行机制甚至可以在适当的情况下为您带来一些性能。

【讨论】：

【解决方案5】：

好吧，如果您想退后一步并在您的项目上工作 2 倍的时间，您不应该使用它 ;-)

我认为没有真正的理由不使用它。由于您可以“数据类型化”工作，因此您更快、更聪明，并且可以少犯错误并拥有更多控制权

【讨论】：

【解决方案6】：

简而言之：不，没有理由不使用 Linq。虽然对于刚接触函数式编程概念的人来说可能有点难以掌握（但只是有点），但一旦你掌握了它，你就会爱上它，而且总体上可以大大提高代码的可读性。

【讨论】：

【解决方案7】：

这取决于您是否将 LINQ to SQL 或 LINQ 称为建模工具。就我个人而言，我使用 LINQ 进行建模只是因为在这方面实际上比我受教育程度低的上司出于多种原因拒绝使用它。一个原因是他们已经完全停止添加新功能，现在只在 LINQ 中维护错误修复。其次是它应该比直接 SQL 慢，这在一定程度上可能在运行低端硬件时是正确的，我不知道。第三是从领域的角度来看，如果你想避开 SQL 注入漏洞，据说使用存储过程是明智的。在我们的所有实例中，我们现在只使用 LINQ 进行建模，存储过程在第一次运行后在服务器上“编译”。

就我个人而言，我只是满足要求，我没有决定权，但是 LINQ 非常适合建模并且包含许多方便的功能。

【讨论】：

你不必使用存储过程来避免SQL注入，使用sql参数应该足以防止这种情况。
比如使用 {0} 进行参数化查询？
不像“SELECT * FROM ATable WHERE AField=@value”和使用 SQL 参数来定义 @value。
不，还不错，这基本上就是 LINQ 在幕后所做的。我不是指使用 LINQ，我指的是使用直接 SQL 和 SQL 命令。
好吧，正如我之前所说，这实际上是 LINQ 在后台生成的内容。这篇文章可能会对你有所帮助thedatafarm.com/blog/data-access/…

【解决方案8】：

LINQ 架构很好 - 但有些人可能更喜欢阅读不使用类似 LINQ SQL 语法的源代码。因此，如果您对可读性要求严格，您可能不想使用该语法。

【讨论】：

可读性不是什么大问题。

【解决方案9】：

我遇到了一些必须解决的问题。例如，根据您的数据库关系的设置方式，您可能会发现 linq2sql 非常适合查询，但无法正确更新。这发生在我身上，我所做的是设置两组 linq 对象。第一个包含我需要的所有关系，因此我可以使用更简单的语法进行查询，但第二个不包含我想要更新时的关系，因为那时我不需要它们。

性能不应成为不使用它的理由，因为通常这只是某些流程的问题。这不像你必须完全使用 linq 或根本不使用。我想很多人认为“哦，直接 sql 更快，而且我需要做一些事情必须很快，所以我不能使用 linq”。不过这很愚蠢。能用的就用，不能用的直接用sql。

【讨论】：

【解决方案10】：

我从各种帖子中可以看出，这取决于需求

LINQ 独立于数据源工作......以相同的方式处理文件对象和数据库
LINQ 可以将多个查询简化为一个
LINQ 具有类型安全性
总体上很好用，开发速度更快
LINQ 仍有许多未解决的问题
LINQ 已停止发展（没有新内容出现）
SQL 更可靠、更高效
SQL 在处理更复杂的查询、存储过程时效果更好
SQL 比 LINQ-SQL 更快

因此，取决于您的项目是否需要不那么复杂的内联查询并涉及查询数据源以外的关系数据库（如 SQL），否则请使用 LINQ，否则请使用良好的旧 SQL 服务器.....:)

【讨论】：

【解决方案11】：

如果您将 LINQ 称为“LINQ to SQL”并且您的 SQL Server 在 Adhoc 查询执行方面存在性能问题，请不要使用 LINQ。

【讨论】：

【解决方案12】：

至于我 - 只有一个理由不使用 LINQ。它是该产品的第三方增强工具。我更喜欢 - 例如Devart LinqConnect。

【讨论】：

【解决方案13】：

LINQ 是一项伟大的技术，但产生的代码很丑陋。如果您认为，您是毕加索的代码，请不要使用它。

在没有 LINQ 的情况下生成代码正在生成可读代码。但我总是使用 ;)

【讨论】：

我也同意，但似乎大多数其他人不同意。我想知道为什么会这样，可能是来自 C 或 ASM 背景而不是来自数据库背景是原因

【解决方案14】：

是的，绝对让事情变得更加可读和简洁。在我在 Visual FoxPro 中使用它的 15 年里确实如此；）

【讨论】：

LINQ 已经存在那么久了？
来自维基百科条目“LINQ 于 2007 年 11 月 19 日作为 .NET Framework 3.5 的一部分发布。”。链接在这里：en.wikipedia.org/wiki/Language_Integrated_Query
我认为这个答案是为了（有点幽默地）指出这样一个事实，即多年来 VFP 具有 LINQ-ish 功能、内存中游标和直接在语言中支持 SQL。