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

Question

我正在考虑将我的开发团队转移到LINQ和Entity框架。如果我这样做，我应该考虑删除SP吗？

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

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

我应该转向类似的事情：

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

如果我离开SP，我会看到多少好处？还有哪些最佳做法？

Answer 1

不，它们不是多余的。

我们使用Entity Framework来获取90％的数据访问代码。

在以下情况中使用10％：

• 当代码在逻辑上过重时（过于复杂）
• 当表现至关重要时
• 当单个交易中需要影响多个记录时

LINQ-Entities（和LINQ，一般而言）是一个精彩且一致的框架，但有时候翻译的SQL并不像你期望的那样最佳 - 额外的JOIN，CASE等等。有时在这些场景中，明智的做法是跳过表达式树转换并直接转到本机SQL。

更重要的是，实体框架提升存储过程。您可以在模型上映射它们，甚至可以将过程直接映射到实体上的CRUD操作。

因此，通常，在大多数简单操作（例如CRUD）中使用EF，并在性能和复杂性是因素时使用存储过程。

HTH。

Answer 2

是的，你应该。

当您使用像Entity Framework这样的ORM时，维护存储过程会产生大量摩擦。 EF生成有效的高性能SQL，并避免SQL注入攻击等问题。

在某些情况下，您可能需要运行需要复杂连接或多个表的异常查询 - 在这些方案中很容易在存储库中公开调用存储过程的特殊方法 - 但对于通用CRUD数据访问，让你的ORM在运行时为你生成SQL并且不再担心它。

（我们过去常常通过存储过程完成所有工作。我们去年切换到NHibernate，从那时起就没有编写过sprocite，并且天空没有落入或者任何东西......）

Answer 3

尝试部分移动到EF（CRUD操作等），但代码的某些部分将使用SP。 第二种情况可以应用于重量级查询，事务，以及何时使用您定义的代码。 通常EF提供开发速度，但是使用SP可以方便地开发一些特定的东西。 SP也给你带来性能提升。