LINQ to SQL、ExecuteQuery等

Question

这可能有点主观：

我们的组织已经进行了一次强有力的尝试，采用LINQ to SQL作为我们的主要数据访问方法，并且在大多数情况下工作得很好。(让我们把EF排除在讨论之外。)

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

那么，公平地说，有些查询太复杂了，以至于不能用LINQ来执行？我们想要避免数据库中的业务逻辑，那么当你不能使用LINQ时，我们该怎么办呢？作为ADO.NET Command.Execute()的更好替代品，人们对ExecuteQuery的总体感觉如何？我认为人们可以反对存储过程，或者至少可以认为避免存储过程是一个有效的选择，但是使用LINQ作为替代来查询视图呢？

有没有想过飞机应该在哪里降落？其他人在做什么？

谢谢,

Answer 1

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

但是，是的，在某些情况下，简单的SQL查询将更容易使用--这很好，没有什么坏处--这就是ExecuteQuery的用途。如果你有一堆CTE和各种类型的复杂连接--你也许能够用Linq- to -SQL来表达它，但是如果你已经有了一个可以工作的T-SQL语句，那么这样做可能太费力太麻烦了……

习惯一种新的做事方式需要时间--给它一些时间！我相信你的大部分开发人员都会逐步迁移到LINQ。鼓励他们，给他们提示和技巧，在你力所能及的地方帮助他们。但也要承认，在同样的情况下，在LINQ中重写棘手的SQL语句可能太难了(如果你已经有了它们，并且它们已经起作用了--只需继续使用它们)。

Answer 2

我还没有找到一个“复杂”到不能用Linq- to -Sql表示的查询。实际上，我发现Linq- to -Sql代码比一些传统的SQL语句更容易阅读。

也就是说，如果这是一个复杂的读取命令，那么我建议您将其放入一个视图中，并通过LINQ访问该视图。您将对连接/有更多的控制，并确保底层SQL被定义为最佳效率。

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

Answer 3

那么，公平地说，有些查询太复杂了，以至于不能用

来执行？

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

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

我们的一些开发人员发现LINQ很困难，于是通过ExecuteQuery迁移回传统的原始

。

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