如果这是一个重复的问题，请道歉，但在执行Linq2Sql中的SQL语句与执行存储过程之间是否存在真正的区别？
有什么好处？ （如果有的话）
答案 0 :(得分：7)
如果将代码放入存储过程，则可以将其与C＃应用程序分离。您可以修复任何错误或扩展其功能，而无需重新编译和重新分发您的应用程序。
此外，使用存储过程可以是一种安全措施：您可以授予您的用户对存储过程的执行权限，但不对基础表授予更新或插入权限。这可以使您的数据库更安全，更易于管理。
纯粹从功能的角度来看，我会说（几乎）你可以在存储过程中做的任何事情都可以使用从Linq-to-SQL DataContext执行的内联SQL来完成 - 但正如我之前提到的那样 - 在这种情况下，您的主应用程序中包含所有SQL代码 - 这可能是好事也可能是坏事，具体取决于您的应用程序和客户的工作和运作方式。
答案 1 :(得分：7)
如果原始速度是 主要问题，请使用DataReader。
否则，LINQ to SQL是一个可靠的替代方案。它在强大的命名和类型安全性方面提供了巨大的好处。这是一个重要的生产力提升。当您学习如何编写良好的LINQ查询时，特别是学会在适当的地方使用编译查询，您可以获得非常不错的性能。
一个精心设计的基于LINQ的程序也不会是一个内存耗尽。是的，数据上下文缓存查询结果，但数据上下文被设计为非常短暂的对象。如果您将数据上下文保留的时间超过单个事务，那么您做错了。如果你在交易结束时处理它们，那么内存损失就会消失。
LINQ to SQL提供了针对SQL注入的最佳保护。存储过程应该是最安全的，但这忽略了这样一个事实：太多人将动态SQL放在存储过程中，这否定了参数化调用的所有安全性。 LINQ to SQL参数化所有内容，虽然它对存储过程非常友好，但它不会运行使用动态SQL的存储过程。
答案 2 :(得分：3)
LINQ to SQL优于存储过程的一个令人难以置信的优势是您可以动态地构建查询。
在存储过程中构建的许多复杂查询很复杂，主要是因为它们是为处理许多可能的情况而构建的。例如，实现具有许多可能参数的过滤器的存储过程（其中一些是可选的）需要构建以适应各种排列并且可能变得非常难看。当然，您可以在LINQ to SQL中构建与一个大型查询相同的查询，但LINQ to SQL的优点在于您不需要。
使用流控制逻辑和查询链接，您可以构建一个更简单的查询，该查询仅使用搜索中活动的那些参数，省略检查或解决未提供可选参数的情况所需的替代逻辑。使用Dynamic LINQ和/或PredicateBuilders，这些查询也可以是任意复杂的 - 但仍然比存储过程实现的查询简单。
要使用存储过程完成同样的事情，您必须编写并维护许多不同的存储过程，每个存储过程执行相似但不相同的工作。然后，您必须使用相同的流逻辑来在这些过程之间进行选择。随着参数数量的增加，这种情况会迅速变得无法实现。
LINQ，IMO的另一个优点是，它允许开发人员使用更自然的习语（在我的例子中，C＃）编写查询。虽然我可以编写SQL，但编写C＃代码对我来说更自然。我更好更快。