【发布时间】：2009-07-08 17:28:05
【问题描述】：
在我的组织中，我们必须向一个单独的 DBA 组负责，以做出使用 LinqToSQL 等决策。您认为使用 L2S 而不是存储过程的最佳理由是什么？
【问题讨论】：
标签： linq-to-sql stored-procedures
【发布时间】：2009-07-08 17:28:05
【问题描述】：
Stackoverflow 问题Linq to SQL vs Stored Procedures? 对双方都有好处。
使用存储过程，您可以更严格地控制查询，当性能很重要时，这可能是一个加分项。您还可以对过程进行更改，而无需重新编译和重新部署，这很方便。
但是，使用 LINQ，您可以获得类型安全，您的 DAL 更容易与项目一起保持版本控制和维护，更容易测试和更好的调试支持。
【讨论】：
-
同意类型安全的事情，这对我来说是最大的好处。
-
我会说 LINQ to SQL 显然不容易测试。鉴于它为您提供了更多的查询构造途径，与存储过程的简单参数列表相比，您需要测试的点要多得多。
我认为这归结为代码集成。您无需查看存储过程，只需查看应用程序中的代码即可。
看看这个链接... http://www.linqpad.net/WhyLINQBeatsSQL.aspx
我还发现构建动态 sql （如 LINQ 查询）的能力看起来不那么动态，而且很容易调试。例如，假设您有一个包含 10 个不同标准/过滤器的搜索页面。如果用户只过滤其中 2 个，您可以创建一个扩展方法，在某些条件为真时在查询中添加 where 过滤器。如果你有一个存储过程，你就会有一堆乱七八糟的东西要调试......
【讨论】：
-
每种方式都有很多利弊，但是决定应用程序架构这样您就不必查看存储过程，这简直是疯了！
-
@KM - 不要以为我曾经建议使用 LINQ 来避免编写存储过程。我经常是单一职责模式的粉丝，我与数据库的连接以及我如何获取数据是某种形式的独立结构......我同意每种方式都有优点/缺点，你需要根据具体情况决定您的 DAO 结构。
-
@RSolberg 说：“我认为它归结为代码集成。您不必查看存储过程，只需查看应用程序中的代码即可。”我将“不必查看存储过程”读为与“因此您不必查看存储过程”相同。
-
这篇文章完全有缺陷。这似乎暗示 LINQ to SQL 是 SQL 的替代品，而实际上它不是。 LINQ to SQL 只是生成 SQL 查询并自己进行映射。与硬编码查询或存储过程相比，LINQ 绝对没有更快的速度，它（在非常、非常好的情况下）根本不慢或不可靠。唯一的优势在于查看代码，而不是查询性能或灵活性。 C# 与 C++ 的比较是虚假的；如果它适用，那将意味着 C# 被编译成 C++，这很愚蠢。
-
en.wikipedia.org/wiki/Single_responsibility_principle，如果你的 LINQ 代码中使用的 DB 表发生了变化，那么你的类也发生了变化，那么它就不符合单一职责模式的要求
您将先前在数据库中的功能移动到您的应用程序中，这可能是好事也可能是坏事。我认为 LinqToSQL 的一个强有力的论点是，如果您必须将存储过程的请求提交给 DBA 组，等待他们完成，然后与他们合作，它可以让您使用 Linq 获得更快的周转时间测试并解决任何问题。您至少可以使用 Linq 进行基本数据访问，然后在需要时使用存储过程（它们有助于缓解性能瓶颈）。
【讨论】：
使用 L2S 时，更多的控制权在应用程序开发人员手中。因此，我想说的是，您可以快速修复某些问题，而无需与 DBA 组进行额外的沟通。
除了以数据为中心的报表，我现在很少使用存储过程。
【讨论】：
【讨论】：
它还可以防止 SQL 注入。
Sprocs 也可以，但如果您使用 linq2sql，DBA 会担心这一点，因此让他们知道这将有助于说服您使用 L2S
L2S 还将允许 DBA 专注于优化数据库及其表结构、索引等，而不必担心支持数据库中的任何存储过程，因为该责任将转移到开发团队。
【讨论】：
-
过程和 Linq2sql 都可以防止这种情况发生。任何参数化查询都可以防止这种情况发生。
-
@bbqchickenrobot：你是对的，但 DBA 不能利用存储过程防止 SQL 注入这一事实来推广存储过程 > linq2sql（我想这就是我真正想说的）
看看这个，这里有点讨论过：
LINQ-to-SQL vs stored procedures?
此外，我们喜欢使用 linq 读取数据并使用存储过程来更新数据，因为我们的存储过程中有一些业务逻辑（不幸的是）。我不同意存储过程中的商业逻辑，但是除了最基本的。双方都可能存在争论，这些争论与您的环境有关。
【讨论】：