将复杂存储过程转换为c# &ADO.Net

本文关键字：ADO Net 复杂 存储过程 转换 | 更新日期: 2023-09-27 18:03:09

这不是关于SPs是好是坏的问题。或者用c#写SQL语句是好是坏。

很快我们就开始了一个新项目，这是一个典型的库存/账单管理系统。这将使用。net和c#作为开发语言。数据库尚未最终确定。

在这个应用程序中不允许使用存储过程，并且它将具有中等到复杂的数据库操作。因此，我可以很容易地使用和SP编写逻辑，现在我必须使用c#和ADO.Net编写。

现在考虑一个非常假设的用例，其中客户选择了5个项目，并准备在柜台....上生成账单这通常包含以下数据库操作:

  • 检查库存表，查看5行物品是否全部可用(数量足够)。
  • 如果任何项不可用-从账单中删除该项并更新账单表
  • 库存表的数量字段将被更新，数量字段将与售出的物品一起扣除。
  • 告警/更新其他表项的阈值数量低于某一点。

现在看看这个场景，这可以很容易地在SP中完成。它包含了很多查询，IF条件，可能的循环等，看起来像一个很好的SP竞争者。我想从专家那里得到的是:

  1. 用c#编写这样的代码有什么最佳实践吗?ADO.Net。在c#中，我们通常可以使用ADO.Net....重新创建相同的代码但这是唯一的方法还是正确的方法?
  2. 我读过很多人说存储过程不好....但是当考虑像这样复杂的场景时，你不觉得存储过程更适合这种情况吗?

将复杂存储过程转换为c# &ADO.Net

在c#中编写这样的代码有什么最佳实践吗?ADO.Net。在c#中，我们通常可以使用ADO.Net....重新创建相同的代码但这是唯一的方法还是正确的方法?

所以我认为基于你的问题，你会更乐意使用像Dapper这样的东西来访问你的数据库。如果你不知道的话，Dapper是一个非常轻量级的数据库访问库，它甚至支持一些更复杂的需求(比如在一次往返中返回多个结果集，然后将这些结果反序列化到POCO类中)。

简而言之，使用Dapper，您可以灵活地查询数据库，并且非常快。

现在，对于一个更具体的例子，Dapper扩展了IDbConnection接口，所以选择什么数据库无关紧要:

数据库尚未完成。

很容易参数化，所以它不受SQL注入的影响:

var parms = new { ID = 1, Bar1 = "Hello" };
var foo = connection.Query<Foo>(
    "SELECT Bar1, Bar2 FROM Foo WHERE ID = @ID AND Bar1 = @Bar1",
    parms);

并且它支持事务，因此您仍然可以将操作作为单个事务来管理:

var tran = connection.BeginTransaction();
var parms = new { ID = 1, Bar1 = "Hello" };
var foo = connection.Query<Foo>(
    "SELECT Bar1, Bar2 FROM Foo WHERE ID = @ID AND Bar1 = @Bar1",
    parms, tran);

并且非常诚实地说，尽管实体框架真的越来越流行，而且微软正在向他们投入大量的钱，但在使用Dapper之后，我不再购买它们了。原因如下。一般来说，利用数据库做它最擅长的事情要好得多，Dapper允许这样做，它所做的就是给你一种机制，通过这种机制，你可以大幅减少从ADO.NET中数据库获取数据并对其执行所需的锅炉板代码。

现在，这是进入存储过程参数的好方法。

我读过很多人说存储过程不好....但是在考虑像这样复杂的场景时，您不觉得存储过程更适合这种情况吗?

存储过程还不错。大多数人说这可能来自两个角度之一:

  1. 他们只是在赶时髦。
    2. 他们对存储过程的目的和好处一无所知。请注意:我没有说愚蠢,我说无知的。

存储过程，不像人们普遍认为的那样，有很好的用途。首先，编译执行计划。其次，它们很容易被参数化，以更快地进行更复杂和多层次的查询——而视图和直接SQL则不然。

我有一个查询，它是一个直接的SQL查询，因为我当时工作的公司也有同样的想法，我把变成一个存储过程，使它的性能提高了98%。这为公司每月节省了2000美元的额外硬件购买费用!

如前所述，使用数据库的优点。我认为这经常被忽略，因为我看到很多人试图使用c#和。net框架对500,000个对象进行排序，但他们不明白为什么它不够快——他们应该在数据库服务器上对它们进行排序!这是真正擅长的一件事!

不要让别人引导你走上一条技术无用和糟糕的道路，因为许多人会告诉你触发器不好，但如果使用得当，它们是完美的!

相关文章：