不使用LINQ的原因
是否有任何好的理由不在我的项目中使用LINQ？ 我们使用.Net 3.5和VSTO 3.0。
就个人而言，我不明白为什么你不想使用它，它使代码更具可读性。
话虽如此，LINQ有时会对某些情况下的性能产生不利影响，这实际上只是我不使用它的原因。
其他答案暗示了这一点，但这里明确指出：
术语“LINQ”可以指L anguage IN tegrated 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.NETentity framework（EF）的一部分。 EF提供了一个更抽象的概念级别的实体建模。 例如，您可能有一个Person实体从两个具有一对一映射的表中获取数据。 访问此实体的代码无需关心如何在数据库中分析表。
我相信LINQ to Entities适用于许多ADO.NET提供程序，而不仅仅是SQL Server。 此外，这也是微软表示将继续投资的地方。
在LINQ到“某个数据库”的这两种情况下，经验丰富的SQL开发人员和/或DBA几乎总是能够编写比LINQ生成的查询更好的查询。 如果性能是最高要求，我相信LINQ to Entities可以将存储过程映射到实体上的方法。
这些LINQ提供程序的最大好处是，当您在性能不是首要任务的环境中工作时，您不需要经验丰富的SQL开发人员或DBA。 这使他们自由地优化了实际需要他们专业知识的查询。
不直接使用这些的另一个原因是，如果您有安全注意事项，则会阻止您的用户对数据库表具有SELECT权限。 在这种情况下，请使用视图或存储过程。
是的，有原因。 我将谈谈在为RDBMS使用各种LINQ提供程序时遇到的一些困难。
LINQ在大多数情况下都很有用，但是当你想构建复杂的查询时（例如在报告应用程序中），它的静态类型性质就成了一个缺点。 例如，有条件地JOIN或有条件地GROUP BY很难，因为结果类型会改变，即使最终你想要投射相同的字段。 LEFT JOIN也很难。 如果您真的很欣赏动态查询，那么SQL和ESQL是更好的选择。
此外，相同的LINQ查询可以（通常是）根据提供程序进行不同的解释，这可能会在切换提供程序时导致意外结果。
关于SQL函数，并非您需要的所有函数都映射到CLR方法，并非所有提供程序都提供了映射函数的可扩展性机制。
最后，性能问题。 将表达式树转换为存储查询可能很昂贵，有时最终结果不是最好的查询。 最优雅的源代码并不总是最好的运行时代码。
唯一的原因是，如果你有一个性能非常关键的应用程序，因为LINQ to Objects查询通常比循环执行更糟糕。 当您可以使用PLINQ的并行处理function时，这将随.Net 4.0而变化。
无论如何，如果你有这样一个性能关键的应用程序，你可能不应该使用托管环境。 在99％的情况下，LINQ将使您的代码更具可读性和更优雅。 它的延迟执行机制甚至可以在适当的情况下获得一些性能。
好吧，如果你想向后退一步并在你的项目上工作2倍，你就不应该使用它;-)
我认为没有真正的理由不使用它。 你更快，更聪明，你可以减少错误并控制更多，因为你可以工作“数据类型”
在一个非常简短的回答中：不，没有理由不使用Linq。 虽然对于熟悉函数式编程概念的人来说可能有点难以理解（但只是稍微有点），一旦掌握了它，你就会喜欢它，并且它通常可以大大提高代码的可读性。
这取决于您是将LINQ to SQL或LINQ称为建模工具。 就个人而言，我只使用LINQ进行建模，因为我的上级实际上在这方面受教育程度低于我，但由于种种原因拒绝了。 一个原因是他们已经完全停止添加新function，现在只维护LINQ中的错误修复。 其次是它应该比直接SQL 慢 ，在运行低端硬件时，这在某种程度上是正确的，我不知道。 第三是域视角，如果你想回避SQL注入漏洞，那么认为使用存储过程是明智的。 在我们的所有实例中，我们现在只使用LINQ进行建模，第一次运行后，存储过程在服务器上“编译”。
就个人而言，我只是满足要求，我没有决定的权力，但LINQ非常适合建模，并包含许多方便的function。
LINQ架构很好 – 但有些人可能更愿意阅读不使用LINQ SQL类语法的源代码。 因此，如果您对可读性严格要求，则可能不希望使用该语法。
我遇到过一些问题，我不得不解决这个问题。 例如，根据数据库关系的设置方式，您可能会发现linq2sql非常适合查询，但无法正确更新。 这发生在我身上，我所做的是设置两组linq对象。 第一个拥有我需要的所有关系，所以我可以使用更简单的语法进行查询，但第二个没有包含我想要更新的关系，因为我不需要它们。
性能不应该是不使用它的原因，因为通常这只是某些进程的问题。 并且它不像你必须完全使用linq或根本不使用linq。 我想很多人都认为“哦，直接sql更快，我需要做的一些事情要快，所以我不能使用linq”。 那真是太傻了。 尽可能使用它，并在不能使用的地方使用直接sql。
我可以从各个post中得出的结论是，这取决于要求
- LINQ独立于数据源工作….以相同的方式处理文件对象和数据库
- LINQ可以将多个查询合并为一个
- LINQ具有类型安全性
- 整体使用良好，开发速度更快
- LINQ仍有很多未解决的问题
- LINQ已经停止发展（没有新的东西出现）
- SQL更可靠，更有效
- 使用更复杂的查询和存储过程时，SQL更好
- SQL比LINQ-SQL快
因此，根据您的项目是否需要内联查询不是那么复杂并涉及查询其他数据源，那么像SQL这样的关系数据库使用LINQ，否则就去找好旧的SQL服务器….. 🙂
如果您将LINQ称为“LINQ to SQL”并且您的SQL Server在Adhoc查询执行方面存在性能问题，请不要使用LINQ。
至于我 – 只有一个原因是不使用LINQ。 它是此产品的第三方增强工具。 我更喜欢 – 例如Devart LinqConnect 。
LINQ是一项伟大的技术，但产生了一个uggly代码。 如果您在想，您是毕加索的代码，请不要使用它。
在没有LINQ的情况下生成代码会产生可读代码。 但我总是使用;）
是的，绝对让事情更具可读性和简洁性。 当然，我在Visual FoxPro中使用了15年;）