c# - 每个小查询的存储过程与硬编码的 sql 查询

<分区>

我正在编写一个 .NET 应用程序并且想知道...我真的应该为我的每个查询编写一个存储过程，还是这里有一些经验？

我知道编写 SP 的好处(例如安全性、不必重新编译代码来更改查询、查询编译)。

但我发现自己很多时候只需要对我的数据库进行简单的选择或删除操作(真的非常简单的东西 - 没有参数) - 那么你认为什么更好 - 为每个和编写一个存储过程每个查询或有一些查询硬编码？我有一些项目，我发现自己有大量的存储过程，正因为如此......

谢谢

最佳答案

存储过程引用了几个选项:

性能:这在很长一段时间内都不是真的 - 现在存储过程和参数化原始命令共享完全相同的缓存
“如果需要，dba 可以更改它”——如果 dba 在没有经过适当的部署过程的情况下更改代码，我不会对他们大喊大叫——如果你的 c# 比 3 次点击更难部署:修复那个
安全性:这个确实有一些优点，但仅限于一些非常有限的场景，比如银行；并注意 - 这里的要点是调用帐户有时没有任何访问原始表的权限:只是存储过程。我们大多数人都不在这种环境中工作

就我个人而言，我很少使用存储过程。原始 SQL 更加灵活 - 明智的 c# 代码可以动态编写适当的 SQL。您也可以在 SQL 中执行此操作，但它不太适合。您还可以使用 ORM 等工具。更重要的是，它避免了一个巨大的部署问题:鸡和蛋存储过程的变化。如果 sproc 变化很大，你不能在不破坏调用者的情况下部署 sproc，并且你不能在不更新 sproc 的情况下更新调用者。而且您有多个服务器调用一个中央数据库。这意味着您需要仔细协调变化，使双方都满意。如果查询在 c# 中，这根本不是问题:当您更新每个单独的服务器时，根据定义使用它期望的查询版本。

基本上，最近我非常喜欢直接参数化 SQL。

关于c# - 每个小查询的存储过程与硬编码的 sql 查询，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20309831/

上一篇：c# - WCF 每个连接服务器证书验证

下一篇：c# - 在 Entity Framework 中获取属性的映射列名称

相关文章：

c# - 如何将文本框样式制作成可重用的控件模板？

c# - 在 ASP.NET Core Web API 项目中保持 Controller 温暖

sql-server - docker容器在bash命令和sql执行后死亡

c# - 哪个线程最先进入临界区？

c# - 如何打开浏览器PDF格式的数据？

mysql - 有关帮助从 MySQL 迁移到 MS SQL 的提示

SQL 条件并集

c# - 使用 Func<TModel, TResult> 而不是内联选择器时的 Linq2SQL n+1

c# - ASP.NET MVC3 中的 Razor 和接口(interface)继承 : why can't this property be found?

c# - 如何使用 C# 从位信息创建 char 数组