将COMPLEX存储过程转换为C＃和ADO.Net
这不是SP是好还是坏的问题。 或者在C＃中编写SQL语句是好还是坏。
我们很快就开始研究一个典型的库存/计费管理系统的新项目。 这将使用.Net和C＃作为语言开发。 数据库尚未最终确定。
在此应用程序中不允许使用存储过程，它将具有中到复杂的数据库操作。 因此，我可以轻松地使用SP编写的逻辑，现在我将不得不使用C＃和ADO.Net编写。
现在采取一个非常假的使用案例，客户选择了5项并准备好在柜台生成账单…. 这通常会有以下数据库操作：
- 检查INVENTORY表以查看是否所有5个订单项都可用（数量足够）。
- 如果任何项目不可用 – 从账单中删除该项目并更新BILL表
- 将更新INVENTORY表的数量字段，并将使用已售出的项目扣除数量字段。
- 警报/更新其他表是项目的阈值数量低于某一点。
现在看一下这个场景，这可以在SP中轻松完成。 这包含很多查询，IF条件，可能的循环等，看起来像SP的一个很好的竞争者。 我想从专家那里得到的是：
- 是否有在C＃和ADO.Net中编写此类代码的最佳实践。 在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( "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( "SELECT Bar1, Bar2 FROM Foo WHERE ID = @ID AND Bar1 = @Bar1", parms, tran);
并且说实话，尽管entity framework真的越来越受欢迎，微软正在向他们投入大量资金，但在使用Dapper后我不再购买它们。 这就是原因。 一般来说，利用数据库获得最佳效果要好得多，Dapper允许这样做，它所做的只是为您提供一种机制，通过该机制可以大大减少从数据库获取数据和执行数据所需的样板代码。 ADO.NET。
现在，这是进入存储过程参数的好方法。
我看过很多人说存储过程很糟糕…… 但是在考虑像这样的复杂场景时……你不觉得存储过程在这种情况下更适合。
存储过程也不错。 并且大多数人声称可能来自两个角度之一：
- 他们只是跳上了潮流。
- 他们对存储过程的目的和好处一无所知。 请注意：我没有说傻 ，我说无知 。
尽管受欢迎，但存储过程仍然有很好的用途。 首先，编译执行计划。 其次，它们很容易参数化，以便更快地进行更复杂的多级查询 – 而视图和直接SQL则不然。 第三，它们更容易为DBA提供保障。
我有一个查询，它是一个直接的SQL查询，因为我当时工作的公司认为完全相同的事情，并且通过将其作为存储过程将其性能提高了98％。 这为公司每月节省了2000美元的额外硬件，他们准备购买！
正如我之前所说， 使用数据库来擅长它。 我认为这经常丢失，因为我看到很多人试图使用C＃和.NET框架对500,000个对象进行排序，他们无法弄清楚为什么它不够快 – 他们应该在数据库服务器上对它们进行排序！ 这是一件非常擅长的事情！
不要让人们引导你走上技术无用而且糟糕的道路，因为许多人会告诉你触发器是坏的， 但是当正确使用它们时它们是完美的！