的LINQ to SQL，的executeQuery等

Question

这可能都有点主观的：

我们的组织作出了采取的LINQ to SQL作为我们的主要数据访问方法的强烈企图，并在大多数情况下这工作得很好。 （让我们将EF留出讨论）

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

那么，说一些查询太复杂以至于无法用LINQ执行，这是否公平？我们希望避免数据库中的业务逻辑，所以当你不能使用LINQ时，我们会去哪里？ ExecuteQuery作为ADO.NET Command.Execute（）的更好选择的一般感觉是什么？我认为可以对存储过程进行争论，或者至少避免它们是一个有效的选择，但是如何使用LINQ作为替代查询Views？

关于何处着陆飞机的想法？别人在做什么？

谢谢，

Answer 1

使用合适的工具进行正确的工作。 Linq-to-SQL涵盖了您在日常业务应用中每天需要完成的大部分工作，因此在那里使用它。开发人员会习惯它，也可能会开始喜欢它 - 它真的非常强大和有用！

但是 - 有确定的情况下，直接的SQL查询将更容易使用 - 这很好，没有损害 - 这是ExecuteQuery的用途。如果您有许多CTE和各种类型的复杂联接 - 您可能可以在Linq-to-SQL中表达，但如果您已经拥有T-SQL语句，则可能会花费太多精力和麻烦那有效......

需要时间去适应新的做事方式 - 给它一些时间！我相信你的大部分开发人员都会逐步迁移到LINQ。鼓励他们，给他们提示技巧，帮助他们，你可以在哪里。但也要接受，在相同的情况下，棘手的SQL语句可能太难以在LINQ中重写（如果您已经拥有它们并且它们已经在工作 - 只是继续使用它们）。

Answer 2

那么，说一些查询太复杂以至于无法用LINQ执行 是否公平？

我会说在大多数情况下没有。毕竟，LINQ to SQL只是一个对象关系映射器。如果使用LINQ to SQL查询很困难，那么对于普通SQL来说，这将会是相同或更难的;再加上你必须手工管理所有数据库到对象的映射。无论如何，作为marc_s点，你有ExecuteQuery例外情况。

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

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

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

Answer 3

我还没有找到一个如此“复杂”的查询，它无法在Linq-to-Sql中表达。事实上，我发现Linq-to-Sql代码比一些传统的SQL语句更容易阅读。这就是说，如果这是一个复杂的READ命令，那么我建议你把它放到VIEW中并通过LINQ访问视图。您可以更多地控制连接/并确保为最佳效率定义底层SQL。

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