asp.net - 在 ASP.NET 应用程序中完全避免临时 SQL 是一个好习惯吗？

Question

而是只创建存储过程并从代码中调用它们？

Answer 1

有一个地方可以使用动态 SQL 和/或即席 SQL，但需要根据特定的使用需求来证明其合理性。

到目前为止，存储过程是几乎所有情况下的最佳实践，应该首先认真考虑。

这个问题比过程或临时问题要大一些，因为数据库有各种各样的工具来定义其接口(interface)，包括表、 View 、函数和过程。

这里的人已经提到了执行计划和参数化，但到目前为止，我认为最重要的是，任何依赖于向用户公开基表的技术都意味着您失去了数据库更改其底层实现的任何能力或垂直或水平控制安全。至少，我只会向典型的应用程序/用户/角色公开 View 。

在应用程序或用户帐户只能访问 EXEC SP 的情况下，该帐户甚至不可能希望使用以下形式的 SQL 注入(inject):"; SELECT name,password from用户；”或“；从用户中删除；”或“；删除表用户；”因为该帐户除了 EXEC 之外没有任何内容(当然也没有 DDL)。例如，您可以在 SP 级别控制列可见性，而不必拒绝对员工薪资列进行选择。

换句话说，除非您愿意将 db_datareader 授予 public(因为这实际上就是您在 LINQ-to-tables 时所做的事情)，否则您的应用程序需要某种实际的安全性，而 SP 是唯一的方法继续，LINQ-to-views 可能是可以接受的。