Question

我对Linq to Sql的理解是它将采用我的Linq语句并将其转换为等效的SQL语句。

所以

var products = from p in db.Products
               where p.Category.CategoryName == "Beverages"
               select p

转身

Select * from Products where CategoryName = 'Beverages'

如果是这种情况，我不会再看到存储过程如何有用了。

Answer 1

Sprocs是盒子里的另一个工具。你可能会使用你喜欢的自动调节扳手来完成90％的任务，但你不能在剥离的螺母上使用闪亮的东西。为此，一个好的'猴子扳手是你最好的朋友。除非你打破螺栓，否则你会遇到装配。

Answer 2

如果这是你在sql中所做的一切，那么你之前不需要使用sprocs！

Answer 3

安全。

我已经看过几条“安全最佳实践”指南，建议您通过SP执行所有数据访问，并且您只授予执行这些SP的权限。
如果客户端无法在任何数据库表上执行select或delete，则客户端被黑客攻击可能会降低风险。

我从未亲自参与一个以这种方式工作的项目，它似乎总是在背后的巨大痛苦。

Answer 4

啊，这是许多辩论的主题。

现在很多人都认为LINQ-to-SQL这样的技术如今产生了如此优秀的SQL，以至于性能优势微不足道。就个人而言，我更喜欢SQL专家调优SQL性能，而不是一般编码器，所以我倾向于不同意。

但是，我对存储过程的主要偏好与性能关系不大，而与安全性和配置管理有关。

我的大部分架构工作都是面向服务的解决方案，并且通过将数据库视为服务，使用存储过程可以显着帮助它。

主要是，通过存储过程限制对数据库的访问会创建一个定义明确的界面，从而限制攻击面积并提高可测试性。允许应用程序直接访问底层数据会大大增加攻击面积，降低安全性，并使影响分析极为困难。

Answer 5

Answer 6

我倾向于使用存储过程有几个原因：

缺点是，如果事情发展迅速，保持调用sprocs的代码与数据库同步可能会很麻烦。有关生成高效查询的要点可能算作过早优化。在一天结束时，实际条件下的基准测试表现无可替代。

Answer 7

我可以想到存储过程的几个很好的理由：

对于由一个人维护的小型应用程序，存储过程可能有点过分。

Answer 8

如果在适当的情况下使用存储过程，则SQL Server方面的性能会有显着提升。

Answer 9

包含对LINQ to SQL的存储过程支持部分是为了与现有系统兼容。这允许开发人员随着时间的推移从基于sproc的系统迁移到完全基于LINQ的系统，而不是强迫开发人员急于一次性转换整个系统。

Answer 10

就个人而言，我不关心LINQ。我喜欢分离数据操作的东西和代码的东西。此外，从LINQ语句生成的匿名类型无法传递到n层应用程序的其他层，因此需要具体定义类型，或者需要在UI中进行LINQ调用。 GACK！

此外，存在安全问题（无论LINQ代码调用MS SQL Server的用户是否需要对数据进行不受限制的访问，因此如果该用户名/密码被泄露，则数据也会受到损害。）

最后，LINQ to SQL仅适用于MS SQL Server（因为它来自MS）。

Answer 11

Sprocs有它们的用途，就像使用LINQ一样。 IMO如果在多个位置执行多次操作，则它是“重构”到存储过程中的良好候选者，而不是在不同位置重复的LINQ语句。

此外，这可能是对很多人的亵渎，有时你应该将一些逻辑放入数据库，然后一个sproc派上用场。这种情况很少发生，但有时业务规则的性质要求它。

Answer 12

存储过程在许多情况下都很有用，但在一般情况下，如果您使用的是ORM，则应让ORM为您生成SQL。为什么我们必须为每个表维护至少四个存储过程（插入更新删除和单个选择）。

据说人们指出使用存储过程有安全上的好处。您不必授予用户对表的读/写权限，这是对SQL注入的良好保护。

当用于检索数据的逻辑相当复杂时，存储过程也很有用。您通常会在Reporting Scenario中看到更多这种情况，在这种情况下，您可能不会使用Linq2Sql或其他ORM。

在我看来，如果您没有生成SQL但基本上在应用层内对其进行硬编码，那么应将其重构为存储过程，是的，总的来说，任何规则都有例外。

Linq2Sql中存储过程的一个用途可能是，如果您有多个服务器，并且链接到它们，您可以使用存储过程公开来自该其他服务器的数据并对其进行操作。这会隐藏应用程序中的多个服务器。

Answer 13

没有存储过程，有些事情是无法完成的。例如，在我之前的工作中，有一个存储过程从一行返回当前值，并在相同的原子操作中递增它，使得没有两个进程都获得相同的值。我不记得为什么这样做而不是使用自动增量，但有一个原因。

Answer 14

原因：要从一个表移动到另一个表的大量数据。

让我们说，偶尔您需要将项目从一个表存档到另一个表或执行类似的操作。使用LINQ意味着从表A中检索一百万行到DBMS客户端，然后将它们插入到表B中。

使用存储过程，一切都很好用。

Answer 15

很多人在没有它们的情况下已经过了一段时间了。如果你能在没有它们的情况下安全高效地完成工作，不要对使用纯L2S感到内疚。我们很高兴在我的商店里摆脱它们。

Answer 16

您当然不需要“存储过程”。但是，如果您的域模型需要复杂的聚合实体，并且您没有足够的奢侈/灵活性来修改数据库表以适合您的域模型，那么它们就会派上用场。在这种情况下，使用Linq-to-SQL或其他ORM可能会导致一组性能非常差的数据库调用来构建您的实体。存储过程可以在这里拯救。

当然，我会提倡使用像TDD / BDD这样的方法或流程，它可以根据需要灵活地修改数据库表，而不会有太多痛苦。在我看来，这总是更容易，更易于维护的路径。

Answer 17

简单示例：

select * from Products where GetCategoryType(CategoryName)=1

GetCategoryType可以非常快地运行，因为它在数据库服务器上运行。据我所知，没有Linq to SQL替代它。

Answer 18

我来这个帖子已经很晚了。但是，根据您与谁交谈，Linq to SQL可以是dead，very dead或at best a zombie。

此外，没有一种工具适合所有情况 - 您需要为手头的特定工作选择合适的工具：