Question

我的系统中有一张订单。用户可以编辑订单表格并将其保存到数据库中。在表单中有一个名为“跟踪订单”的复选框字段，如果选中该字段，则会将订单ID添加到TrackedOrders表中。

现在，我的问题是，哪种解决方案更好：

使用单个存储过程（SaveOrder），它首先使用UPDATE语句更新所有Order字段，如果“isTrackedOrder”，则在内部调用另一个SP（AddTrackedOrders） checkbox value = true。
或致电SaveOrder sp，它只会更新订单，然后检入应用代码if isTrackedOrder=true -> call AddTrackedOrders。

两个电话都必须在同一个交易中！意味着如果SaveOrder成功且AddTrackedOrders失败，那么SaveOrder也必须回滚。

我知道可以在代码中创建交易，但我不确定这种方法的含义是什么。

编辑：

经过短暂的研究后，我注意到大多数人更喜欢使用TransactionScope。我仍然不确定这是如何更好，因为它使trasaction时间更长（因此更容易出错）并使多个数据库往返。另外，如果结果控制业务场景的流程，您可能需要添加更多存储过程...

全部谢谢！

Answer 1

我个人更喜欢在代码中执行业务逻辑，而不是在数据库中执行业务逻辑有各种原因（C＃vs SQL，代码版本控制，可重用性等等）。

您可以将代码和存储过程调用包装在TransactionScope中以原子方式执行：

using(TransactionScope scope = new TransactionScope())
{
    // Executes some business logic against the DB using a DB context
    ...

    // Executes some stored procedure here
    ...

    // commits transaction
    scope.Complete();
}

Answer 2

您有几个选择：存储过程，代码中的事务和工作单元模式。

我强烈建议实施工作单元模式来管理代码中的事务，而不是在一次性情况下管理事务或实现存储过程。

存储过程曾经是要走的路，主要是因为性能。但是，随着最近SQL Server实现中动态查询的性能优化的改进，这变得不那么令人担忧（尽管在某些边缘情况下仍然可能存在一个小优势）。而且，性能不再是优势，将逻辑集中在代码中与您的其他业务逻辑相结合会越来越有意义。

工作单元模式将允许您更轻松地通过代码管理您的交易，并且它将支持多层交易（交易中的交易）。

使用Entity Framework（或任何ORM）更容易实现工作单元，但如果您致力于ADO.NET而不使用ORM，则有很多方法可以实现。 This article给出了实现UoW w / ADO.NET的非常好的概述。

存储过程或应用程序中的业务逻辑

2 个答案: