我正在考虑将我的开发团队转移到 LINQ 和实体框架。如果这样做，我是否应该考虑删除 SP？
通常我们的架构是（按顺序）；
SQL -> SPs -> Data Access Layer -> Business Objects -> GUI
我应该转向类似的事情吗：
SQL -> Entity Framework Layer -> Business Objects (probably inherited from EF layer) -> GUI
如果我保留 SP，我会看到同样多的好处吗？还有什么最佳实践？
不，它们并不多余。
我们 90% 的数据访问代码都使用实体框架。
这10%用于以下场景：
LINQ-Entities（一般来说，LINQ）是一个出色且一致的框架，但有时翻译的 SQL 并不像您期望的那样优化 - 额外的 JOIN、CASE 等。有时在这些情况下，跳过表达式树翻译并直接进入本机 SQL。
更重要的是，实体框架促进存储过程。您可以将它们映射到模型上，甚至可以将过程直接映射到实体上的 CRUD 操作。
所以一般来说，对于大多数简单的操作（例如 CRUD）使用 EF，当性能和复杂性是因素时使用存储过程。
是的，你应该这样做。
当您使用实体框架等 ORM 时，维护存储过程会产生大量摩擦。 EF 生成有效、高性能的 SQL，并避免诸如 SQL 注入攻击之类的事情。
在某些情况下，您可能需要运行需要复杂联接或多个表的异常查询 - 在这些情况下，很容易在存储库上公开调用存储过程的特殊方法 - 但对于通用 CRUD 数据访问，只需让您的 ORM 在运行时为您生成 SQL，而无需担心它。
（我们以前都是通过存储过程来做所有事情。我们去年切换到NHibernate，从那以后就没有写过存储过程，天也没有塌下来什么的......）
尝试部分转移到 EF（CRUD 操作等），但代码的某些部分会使用 SP。 第二种情况可以应用于重量级查询、事务以及当您想要使用您定义的代码时。 一般来说EF提供了开发速度，但是一些特定的东西使用SP可以方便地开发。此外，SP 始终能够提升您的性能。