【发布时间】：2010-03-01 12:56:30
【问题描述】：
抱歉，如果这是一个重复的问题，但是在 Linq2Sql 中执行 SQL 语句与执行存储过程之间有真正的区别吗？
有什么好处？ （如果有的话）
【问题讨论】：
标签： .net sql linq-to-sql
【发布时间】：2010-03-01 12:56:30
【问题描述】：
如果您将代码放入存储过程中，则您已将其与 C# 应用程序分离。您可以修复任何错误或扩展其功能，而无需重新编译和重新分发您的应用程序。
此外，使用存储过程可以作为一种安全措施：您可以授予用户对存储过程的执行权限，但不能授予对基础表的更新或插入权限。这可以使您的数据库更安全、更易于管理。
纯粹从功能的角度来看，我想说（几乎）您在存储过程中可以做的任何事情也可以通过从 Linq-to-SQL DataContext 执行的内联 SQL 来完成 - 但正如我之前提到的 - 在这种情况下，您的所有 SQL 代码都在您的主应用程序中 - 这可能是好事也可能是坏事，这取决于您的应用程序和您的客户如何工作和运作。
【讨论】：
-
虽然使用存储过程确实可以将数据逻辑与应用程序代码分离，但您可以在单独编译并通过跨平台访问的单独数据层程序集中编写 Linq-to-SQL一个界面。诚然，您仍然需要重新编译/部署数据访问程序集，但它确实解耦了数据访问逻辑。
如果原始速度是主要关注点，则使用 DataReader。
否则，LINQ to SQL 是一个可靠的替代方案。它在强大的命名和类型安全方面提供了巨大的好处。这是一个重大的生产力提升。当您学习如何编写良好的 LINQ 查询，尤其是学习在适当的情况下使用编译查询时，您可以获得非常不错的性能。
设计良好的基于 LINQ 的程序也不会占用大量内存。是的，数据上下文缓存了查询结果，但是数据上下文被设计为一个非常短暂的对象。如果您将数据上下文保持在比单个事务更长的时间，那么您做错了。如果您在交易结束时处理它们，那么内存丢失就消失了。
LINQ to SQL 提供了针对 SQL 注入的最佳保护。存储过程被认为是最安全的，但这忽略了太多人将动态 SQL 放在存储过程中的事实，这否定了参数化调用的所有安全性。 LINQ to SQL 参数化了一切，虽然它对存储过程非常友好，但它不会运行使用动态 SQL 的存储过程。
【讨论】：
-
+1 表示“如果您将数据上下文保留的时间超过单个事务，那么您做错了”
LINQ to SQL 优于存储过程的一个令人难以置信的优势是您可以动态构建查询。
存储过程中内置的许多复杂查询之所以复杂，主要是因为它们是为处理许多可能的情况而构建的。例如，一个存储过程实现了一个带有许多可能参数的过滤器，其中一些参数是可选的，需要构建以适应各种排列，并且可能会变得非常丑陋。当然，您可以在 LINQ to SQL 中构建与一个大型查询相同的查询，但 LINQ to SQL 的美妙之处在于您不需要这样做。
通过使用流控制逻辑和查询链接，您可以构建一个更简单的查询，该查询仅使用那些在搜索中处于活动状态的参数，而忽略处理未提供可选参数的情况所需的检查或替代逻辑。使用Dynamic LINQ 和/或PredicateBuilders，这些查询也可以任意复杂——但仍然比存储过程实现的更简单。
要使用存储过程完成相同的任务，您必须编写并维护许多不同的存储过程，每个存储过程都执行类似但不同的工作。然后，您必须具有相同的流程逻辑才能在这些过程之间进行选择。随着参数数量的增加，这很快变得站不住脚。
LINQ IMO 的另一个优点是它允许开发人员使用更自然的习惯用法（在我的例子中是 C#）来编写查询。虽然我可以编写 SQL，但编写 C# 代码对我来说更自然。我在这方面做得更好更快。
【讨论】：