这可能都有点主观：
我们的组织已经大力尝试采用LINQ to SQL作为我们的主要数据访问方法，并且大多数情况下这都很有效。 （让我们将EF留在讨论之外。）
我们的一些开发人员发现LINQ很难，并通过ExecuteQuery迁移回传统的原始SQL。我们还在一些应用程序中使用OpenQuery来访问远程服务器上的数据。 OpenQuery不能通过LINQ执行，并且总是导致代码通过ExecuteQuery执行。作为一个组织，我们还决定放弃存储过程并再次依赖LINQ。
那么，说一些查询是如此复杂以至于无法使用LINQ执行是否公平？我们想避免数据库中的业务逻辑，那么当你不能使用LINQ时我们会去哪里？ ExecuteQuery作为ADO.NET Command.Execute（）的更好替代品的一般感觉是什么？我认为可以针对存储过程进行论证，或者至少避免它们是一个有效的选择，但是如果用LINQ作为替代方法查询视图呢？
关于飞机降落在哪里的想法？别人在做什么？
谢谢，
答案 0 :(得分：3)
我还没有找到一个如此“复杂”的查询，它无法在Linq-to-Sql中表达。事实上，我发现Linq-to-Sql代码比一些传统的SQL语句更容易阅读。
那就是说，如果这是一个复杂的READ命令，那么我建议你把它放到VIEW中并通过LINQ访问视图。您可以对连接进行更多控制，并确保定义基础SQL以获得最佳效率。
此外，您可以在Linq-To-Sql中调用存储过程和/或函数。您在传统SQL进程中创建存储过程的原因与您在Linq-To-Sql中执行此操作的原因相同。让我们重申一下：没有什么可以阻止您从Linq-to SQL运行存储过程。当我需要影响大量记录时（例如，对记录进行批量更改），我会这样做。
答案 1 :(得分：2)
使用正确的工具来完成正确的工作。 Linq-to-SQL在一个典型的业务线应用程序中涵盖了您每天需要做的大部分工作 - 所以在那里使用它。开发人员会习惯它，也可能会开始喜欢它 - 它真的非常强大和有用！
但是 - 有明确的情况，直接的SQL查询将更容易使用 - 这很好，没有坏处 - 这就是ExecuteQuery的用途。如果你有一堆CTE和各种类型的复杂连接 - 你可能能够在Linq-to-SQL中表达它，但如果你已经有一个T-SQL语句，它可能只是太费劲和麻烦有效....
习惯一种新的做事方式需要时间 - 给它一些时间！我相信你的大多数开发人员都会逐步迁移到LINQ。鼓励他们，给他们提示＆amp;技巧，尽你所能帮助他们。但同时也接受，在相同的情况下，棘手的SQL语句可能只是太难以在LINQ中重写（如果你已经拥有它们并且它们已经可以工作 - 只需继续使用它们。）
答案 2 :(得分：1)
所以，说一些查询是如此复杂以至于它们是否公平 不能用LINQ执行？
对于大多数情况，我会说不。毕竟，LINQ to SQL只是一个对象关系映射器。如果使用LINQ to SQL进行查询很困难，那么使用纯SQL将会遇到相同或更困难的问题;另外，您必须手动管理所有数据库到对象的映射。无论如何，当marc_s指出时，对于例外情况你有ExecuteQuery。
自从我发布以来，我在所有新项目中都使用了LINQ to SQL（从简单的数据库到复杂的数据库），并且在100％的情况下，它简化了我的工作并允许我编写更易读和可维护的代码。
我们的一些开发人员找到了LINQ 困难并迁移回来 通过ExecuteQuery传统的原始SQL。
我认为很难相信，除非他们害怕学习新事物。如果他们能够设法在LINQ中形成自己（通过阅读书籍，博客或技术文章;或通过课程或指导），他们肯定会发现这是值得的。