LINQ to SQL、ExecuteQuery 等答案

【问题标题】：LINQ to SQL, ExecuteQuery, etcLINQ to SQL、ExecuteQuery 等
【发布时间】：2010-12-18 19:43:49
【问题描述】：

这可能有点主观：

我们的组织已经做出了强有力的尝试，将 LINQ to SQL 作为我们的主要数据访问方法，并且在大多数情况下效果很好。（让我们把 EF 排除在讨论之外。）

我们的一些开发人员发现 LINQ 很困难，并通过 ExecuteQuery 迁移回传统的原始 SQL。我们还在一些应用程序中使用 OpenQuery 来访问远程服务器上的数据。 OpenQuery 不能通过 LINQ 执行，并且总是导致代码通过 ExecuteQuery 执行。作为一个组织，我们还决定放弃存储过程并再次依赖 LINQ。

那么，是否可以说某些查询非常复杂以至于无法使用 LINQ 执行？我们想避免数据库中的业务逻辑，那么当您不能使用 LINQ 时我们该去哪里？ ExecuteQuery 作为 ADO.NET Command.Execute() 的更好替代方案的总体感觉是什么？我认为人们可以反对存储过程，或者至少可以避免使用存储过程是一种有效的选择，但是使用 LINQ 查询视图作为替代方案呢？

想好飞机在哪里降落了吗？其他人在做什么？

谢谢，

【问题讨论】：

标签： asp.net sql linq-to-sql ado.net

【解决方案1】：

我还没有找到一个“复杂”到无法在 Linq-to-Sql 中表达的查询。事实上，我发现 Linq-to-Sql 代码比一些传统的 SQL 语句更容易阅读。

也就是说，如果这是一个复杂的 READ 命令，那么我建议您将其放入 VIEW 并通过 LINQ 访问该视图。您可以更好地控制连接/并确保定义底层 SQL 以获得最佳效率。

此外，您可以在 Linq-To-Sql 中调用存储过程和/或函数。在传统 SQL 过程中创建存储过程的原因与在 Linq-To-Sql 中创建存储过程的原因相同。让我们重申一下：没有什么能阻止您从 Linq-to-SQL 运行存储过程。当我需要影响许多记录时（例如，对记录进行批量更改），我会这样做。

【讨论】：

【解决方案2】：

为正确的工作使用正确的工具。 Linq-to-SQL 涵盖了您在典型的业务线应用程序中每天需要做的大部分事情 - 所以在那里使用它。开发者会习惯它，并且可能也会开始喜欢它——它真的非常强大和有用！

但是是的——在某些情况下，直接的 SQL 查询会更容易使用——这很好，没有坏处——这就是 ExecuteQuery 的用途。如果你有一堆 CTE 和各种类型的复杂连接 - 你可能能够在 Linq-to-SQL 中表达它，但如果你已经有一个 T-SQL 语句，这样做可能会花费太多精力和麻烦这行得通....

适应一种新的做事方式需要时间 - 给它一些时间！我确信您的大多数开发人员将逐步迁移到 LINQ。鼓励他们，给他们提示和技巧，在可能的地方帮助他们。但也要接受，在同样的情况下，棘手的 SQL 语句可能太棘手而无法在 LINQ 中重写（如果您已经拥有它们并且它们已经工作 - 继续使用它们）。

【讨论】：

【解决方案3】：

那么，可以公平地说，有些查询是如此复杂以至于它们不能用 LINQ 执行？

对于大多数情况，我会说不。毕竟 LINQ to SQL 只是一个对象关系映射器。如果使用 LINQ to SQL 进行查询很困难，那么使用普通 SQL 将变得相同或更困难；另外，您必须手动管理所有数据库到对象的映射。无论如何，正如 marc_s 指出的那样，您有 ExecuteQuery 用于特殊情况。

自从发布以来，我在所有新项目中都使用了 LINQ to SQL（从琐碎的数据库到复杂的数据库），在 100% 的情况下，它简化了我的工作，让我可以编写更易读和可维护的代码。

我们的一些开发人员发现 LINQ 困难并迁移回通过 ExecuteQuery 实现的传统原始 SQL。

我认为这很难相信，除非他们完全害怕学习新事物。如果他们能够设法在 LINQ 中形成自己（通过阅读书籍、博客或技术文章；或者通过课程或指导），那么他们肯定会发现这是值得的。

【讨论】：