不使用LINQ的原因

Question

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

Answer 1

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

话虽如此，LINQ有时会对某些情况下的性能产生不利影响，这实际上只是我不使用它的原因。

Answer 2

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

术语“LINQ”可以指 L anguage IN 整合 Q uery的整套技术。这些技术允许将LINQ查询转换为表达式树。该树可以在以后由“LINQ Provider”执行。

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

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

---

许多LINQ提供商都提供额外的工具（有些人会说，“行李”）。这个工具有助于提供关于LINQ的一些最常见的“利弊”。

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

我认为LINQ to SQL仅限于Microsoft SQL Server。此外，微软已经表示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权限。在这种情况下，请使用视图或存储过程。

Answer 3

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

LINQ在大多数情况下效果很好，但是当你想构建复杂的查询时（例如在报告应用程序中），它的静态类型性质就成了一个缺点。例如，有条件地JOIN或有条件地GROUP BY很难，因为结果类型会改变，即使最终你想要投射相同的字段。 LEFT JOIN也很难。如果你真的很喜欢动态查询，那么SQL和ESQL是更好的选择。

此外，相同的LINQ查询可能（通常是）根据提供程序进行不同的解释，这可能会在切换提供程序时导致意外结果。

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

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

Answer 4

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

无论如何，如果你有这样一个性能关键的应用程序，你可能不应该使用托管环境。在99％的情况下，LINQ将使您的代码更具可读性和更优雅。它的延迟执行机制甚至可以在适当的情况下获得一些性能。

Answer 5

好吧，如果你想向后退一步并在你的项目上工作2倍，你就不应该使用它; - ）

我认为没有正当理由不使用它。你更快，更聪明，你可以减少错误并控制更多，因为你可以工作“数据类型”

Answer 6

在一个非常简短的回答中：不，没有理由不使用Linq。虽然对于熟悉函数式编程概念的人来说可能有点难以掌握（但是只是略微），一旦掌握了它，你就会喜欢它，并且它通常可以大大改善代码的可读性。

Answer 7

这取决于您是将LINQ to SQL还是LINQ作为建模工具。我个人使用LINQ进行建模只是因为我的上级在这个领域实际上比我受教育程度低，但由于种种原因拒绝了。一个原因是他们已经完全停止添加新功能，现在只维护LINQ中的错误修复。其次是它应该比直接SQL 更慢，这在某种程度上可能在运行低端硬件时也是如此，我不知道。第三是域视角，如果你想回避SQL注入漏洞，那么认为使用存储过程是明智的。在我们的所有实例中，我们现在只使用LINQ进行建模，第一次运行后，存储过程在服务器上“编译”。

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

Answer 8

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

Answer 9

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

性能不应成为不使用它的理由，因为通常这只是某些进程的问题。并且它不像你必须完全使用linq或根本不使用linq。我想很多人都认为“哦，直接sql更快，我需要做的一些事情要快，所以我不能使用linq”。那真是太傻了。尽可能使用它，并在不能使用的情况下使用直接sql。

Answer 10

我可以从各个帖子中得知，这取决于要求

• LINQ独立于数据源工作....以相同的方式处理文件对象和数据库
• LINQ可以将多个查询减少为一个
• LINQ具有类型安全
• 整体使用方便，发展更快
• LINQ仍有很多未解决的问题
• LINQ已经停止演变（没有新的东西出现）
• SQL更可靠，更有效率
• 使用更复杂的查询和存储过程时，SQL会更好。
• SQL比LINQ-SQL
更快

因此，根据您的项目是否要求内联查询不那么复杂并且涉及查询其他数据源，那么像SQL这样的关系数据库使用LINQ，否则就去找好旧的SQL服务器..... :)

Answer 11

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

Answer 12

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

Answer 13

LINQ是一项很棒的技术，但会生成一个uggly代码。如果你在想，你是毕加索的代码就不要使用它。

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

Answer 14

是的，绝对让事情更具可读性和简洁性。当然，我在Visual FoxPro中使用了15年;）