实体SQL或StoredProcedure，使用什么？

Question

我可以选择在 DAL 中使用实体SQL查询，或者在 db 中使用存储过程作为一种选择。

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

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

Answer 1

根据我的经验：

实体框架：

• 逻辑保留在应用程序中
• 更容易与源代码管理集成（根据我的经验）
• 如果需要，也可以使用存储过程（我在全文搜索例程中使用它）
• 数据库不可知 - ＆gt;好吧，我之前没有真正尝试更改db，但它应该保护你免受基础持久性存储
的影响
• 个人偏好：获得一系列对象/模型而不是笨重的数据，它更漂亮，更方便..更不用说我 需要知道列的顺序等......

数据库SP

• 您不必学习任何新内容 - 某些任务从存储过程中可以轻而易举，但在使用EF时可能会令人烦恼。嗯，这取决于你赶上的速度。
• 易于使用，更精细控制 - 直到现在，我不知道如何在linq中创建一个使用WITH和OVER（）的查询实体..

就个人而言，由于我上面提到的原因（以及我现在无法想到的其他一些原因），我也会选择EF。此外，如果有一些我无法做到或无法快速执行linq查询，我只会创建一个存储过程或只是执行一条SQL语句（是的，你可以使用上下文执行SQL）。

Answer 2

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

但是，如果您了解SQL（或其他人负责SQL Server性能），那么请使用存储过程。在不重新发布应用程序的情况下优化数据库操作要容易得多。

Answer 3

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

实体SQL从SQL注入攻击中是安全的，因为它始终参数化 但是如果你对SQL有足够的了解，你就会看到存储过程更加谨慎的情况。

您知道可以在实体框架中使用存储过程吗？
宁愿建议实体框架。在特定情况下使用存储过程存储过程更加优化。

Answer 4

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

1. 为了得到一些数据，你应该向数据库发出超过2个请求 - 为什么要从脚本发送它，更容易编写一个proc，它将在db中完成所有操作并且只向你发送resalts（它太快了）
2. 如果简单地编写一个proc并花费5分钟而不是一个天才的实体并花费1天
3. 如果默认情况下某些操作在db中运行速度更快或实体不支持