当我有LINQ to SQL时,为什么需要存储过程

我对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'

如果是这种情况,我不会看到存储过程如何有用.

1> 小智..：

---

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

2> Steven A. Lo..：

---

如果这是你在sql中所做的一切,你之前不需要使用sprocs!

3> Orion Edward..：

---

安全.

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

我从来没有亲自参与过以这种方式工作的项目,它总是看起来像背后的巨大痛苦.

---

实际上,它根本不是一个痛苦的屁股.我曾经做过的每个项目都是这样做的.

---

我自己喜欢这种方法..它缩小了对一小组易于管理的通道(存储过程)的所有数据库访问

4> Steve Morgan..：

---

啊,很多辩论的主题.

如今,许多人都认为LINQ-to-SQL等技术能够产生如此优秀的SQL,以至于性能优势微不足道.就个人而言,我更喜欢SQL专家调优SQL性能,而不是一般编码器,所以我倾向于不同意.

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

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

原则上,通过存储过程限制对数据库的访问会创建一个定义明确的界面,从而限制攻击面积并提高可测试性.允许应用程序直接访问底层数据会大大增加攻击面积,降低安全性,并使影响分析变得非常困难.

5> yfeldblum..：

---

存储过程和Linq to Sql解决了不同的问题.

Linq to Sql特别适用于Microsoft SQL Server.

---

@J0rd4n:LINQ to SQL _is_特别是SQL Server.LINQ不是.

6> 小智..：

---

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

它使安全配置更容易(如其他海报所述).

它为数据库访问提供了一个明确定义的接口(尽管这可以转移到其他领域,例如用C#编写的DAL)

我发现至少在Oracle中,查询优化器能够根据您提供的信息做出更明智的决策.尽管如此,这确实需要使用这两种方法进行测试.

根据可用的开发人员,您可能有一些非常好的SQL编码器,如果他们使用sprocs,他们会更好地生成有效的查询.

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

7> Andomar..：

---

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

使用较大的表时,使用LINQ to SQL生成有效的查询很困难.

DBA可以分析和解决存储过程.但想想当来自不同前端的两个复杂的LINQ操作发生冲突时会发生什么.

存储过程可以强制执行数据完整性.拒绝对表进行写访问,并仅允许通过存储过程进行更改.

更新存储过程就像在服务器上运行ALTER PROCEDURE一样简单.如果部署需要数月和脚本分钟,则存储过程将更加灵活.

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