这可能有点主观:
我们的组织已大力尝试采用 LINQ to SQL 作为我们的主要数据访问方法，并且在大多数情况下效果很好。 (让我们将 EF 排除在讨论之外。)
我们的一些开发人员发现 LINQ 很困难，并通过 ExecuteQuery 迁移回传统的原始 SQL。我们还在一些应用程序中使用 OpenQuery 来访问远程服务器上的数据。 OpenQuery 无法通过 LINQ 执行，并且始终会导致代码通过 ExecuteQuery 执行。作为一个组织，我们还决定放弃存储过程并再次依赖 LINQ。
那么，可以说某些查询非常复杂以至于无法使用 LINQ 执行吗？我们想避免数据库中的业务逻辑，那么当您不能使用 LINQ 时，我们该去哪里呢？ ExecuteQuery 作为 ADO.NET Command.Execute() 的更好替代方案的总体感觉如何？我认为人们可以反对存储过程或至少避免使用存储过程是一个有效的选择，但是使用 LINQ 查询 View 作为替代方案呢？
关于飞机在何处着陆的想法？其他人在做什么？
谢谢，
最佳答案
我还没有找到一个“复杂”到无法用 Linq-to-Sql 表达的查询。事实上，我发现 Linq-to-Sql 代码比一些传统的 SQL 语句更容易阅读。
也就是说，如果这是一个复杂的 READ 命令，那么我建议您将它放入一个 VIEW 中并通过 LINQ 访问该 View 。您可以更好地控制连接/并确保定义底层 SQL 以获得最佳效率。
此外，您可以在 Linq-To-Sql 中调用存储过程和/或函数。在传统 SQL 过程中创建存储过程的原因与在 Linq-To-Sql 中创建存储过程的原因相同。让我们重申一下:没有什么可以阻止您从 Linq-to-SQL 运行存储过程。当我需要影响大量记录时(例如，对记录进行批量更改)，我会这样做。
关于asp.net - LINQ to SQL、ExecuteQuery 等，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1771965/