Entity SQL 还是 StoredProcedure，该用什么？

Question

我可以选择在 DAL 中使用Entity SQL 查询，或者在 db 级别使用存储过程作为选项。

我应该使用哪一个。这两种方法的优点/缺点是什么？

我更倾向于Entity SQL，因为我不希望我的逻辑以任何形式的数据库级别暴露。

Answer 1

根据我的经验：

实体框架：

• 逻辑保留在应用程序中
• 更容易与源代码控制集成（根据我的经验）
• 如果需要，还可以使用存储过程（我在全文搜索例程中使用它）
• 与数据库无关 ->好吧，我之前没有真正尝试过更改数据库，但它应该可以保护您免受底层持久性存储的影响。
• 个人偏好：获取对象/模型数组而不是庞大的数据表更加漂亮和方便..更不用说那我
  需要知道列的顺序等等......

数据库 SP

• 您不必学习任何新东西 - 有些任务对于存储过程来说是微不足道的，但在使用 EF 时可能会非常令人烦恼地晦涩难懂。好吧，这取决于你追赶的速度。
• 易于使用，更精细的控制 - 到目前为止，我不知道如何创建一个在实体的 linq 中使用 WITH 和 OVER() 的查询。

就我个人而言，我也会使用 EF，因为我已经上面提到的（加上我现在想不起来的其他一些）。此外，如果我无法使用 linq 查询执行或无法快速执行某些操作，我将仅创建一个存储过程或仅执行一条 SQL 语句（是的，您可以使用上下文执行 SQL）。

Answer 2

如果您也是数据库管理员，请使用 LINQ 实体。
如果将代码放在一起会更容易。

但是，如果您熟悉 SQL（或者其他人负责 SQL Server 性能），则可以使用存储过程。无需重新发布应用程序即可更轻松地优化数据库操作。

Answer 3

两者都有自己的优点和缺点。

Entity SQL 始终参数化，因此可以免受 SQL 注入攻击。
但如果您足够了解 SQL，您会发现存储过程会更加谨慎。

您知道可以在实体框架中使用存储过程吗？
更愿意建议实体框架。当您觉得在特定场景中存储过程更加优化时，请使用存储过程。

Answer 4

我仅在以下情况下使用 StoredProc：

1. 为了获取一些数据，您应该向数据库发出超过 2 个请求 - 为什么要从脚本发送它，编写一个过程会更容易，该过程将完成数据库中的所有操作，并且只向您发送结果（它太快得多）
2. 如果编写一个过程并花费 5 分钟比编写一个天才实体花费 1 天更简单
3. 如果某些操作默认在数据库中运行得更快或不受实体支持