如果使用 Linq 和 EF，SP 是否多余（最佳实践）答案

【问题标题】：Are SPs redundant if using Linq and EF (best practice)如果使用 Linq 和 EF，SP 是否多余（最佳实践）
【发布时间】：2010-12-23 10:28:43
【问题描述】：

我正在考虑将我的开发团队转移到 LINQ 和实体框架。如果我这样做了，我是否应该考虑移除 SP？

通常我们的架构是（按顺序）；

SQL -> SPs -> Data Access Layer -> Business Objects -> GUI

我应该转向类似的东西吗：

SQL -> Entity Framework Layer -> Business Objects (probably inherited from EF layer) -> GUI

如果我把 SP 留在里面，我会看到同样多的好处吗？还有哪些最佳做法？

【问题讨论】：

【解决方案1】：

不，它们不是多余的。

我们 90% 的数据访问代码都使用实体框架。

这 10% 用于以下场景：

LINQ-Entities（和一般的 LINQ）是一个出色且一致的框架，但有时翻译的 SQL 并不像您期望的那样最佳 - 额外的 JOIN、CASE 等。有时在这些情况下，明智的做法是跳过表达式树翻译，直接进入原生 SQL。

此外，实体框架促进存储过程。您可以将它们映射到模型上，甚至可以将过程直接映射到实体上的 CRUD 操作。

因此，一般来说，将 EF 用于大多数简单操作（例如 CRUD），并在考虑性能和复杂性时使用存储过程。

HTH。

【讨论】：

【解决方案2】：

是的，你应该这样做。

当您使用像实体框架这样的 ORM 时，维护存储过程会产生巨大的摩擦。 EF 生成有效、高性能的 SQL，并避免诸如 SQL 注入攻击之类的事情。

在某些情况下，您可能需要运行需要复杂联接或多个表的异常查询 - 在这些情况下，很容易在存储库上公开一个调用存储过程的特殊方法 - 但用于通用 CRUD 数据访问，只需让您的 ORM 在运行时为您生成 SQL 即可。

（我们过去都是通过存储过程来做所有事情。我们去年切换到 NHibernate，从那以后就没有写过存储过程，天也没有塌下来什么的......）

【讨论】：

【解决方案3】：

只需尝试部分移动到 EF（CRUD 操作等），但您的某些代码使用 SP 离开。第二种情况可以应用于重量级的查询、事务，以及当你想使用你定义的代码时。一般 EF 提供开发速度，但有些特定的东西可以方便地使用 SP 进行开发。此外，SP 总能给您带来性能提升。

【讨论】：