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

我的系统中有订单。用户可以编辑订单并将其保存到数据库。在表单中有一个复选框字段，名为“跟踪订单”，如果选中，则将订单ID添加到TrackedOrders表中。存储过程或应用程序中的业务逻辑

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

要使用UPDATE语句中使用单个存储过程（SaveOrder），它首先更新所有的订单字段和调用另一个SP（AddTrackedOrders）内部，如果“isTrackedOrder”复选框值= true。
或致电SaveOrder sp将只更新订单，然后签入应用程序代码if isTrackedOrder=true -> call AddTrackedOrders。

这两个调用都必须在同一个事务中！意味着如果SaveOrder成功并且AddTrackedOrders失败，那么SaveOrder也必须回滚。

我知道有可能在代码中创建事务，但我不确定这种方法的含义是什么。

编辑：

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

谢谢大家！

来源

2013-11-21 Uri Abramson

只要有可能，最好不要使用存储过程。 – Dennis

但是，那么我将如何管理代码中的交易？ –

无论您使用哪种数据访问机制，从.NET代码管理事务都没有任何困难。 – Dennis

我个人更喜欢执行业务逻辑代码，而不是在数据库因各种原因（C＃与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(); 
}

来源

2013-11-21 13:21:50 ken2k

它不需要多次往返数据库？ –

@UriAbramson它有什么关系？如果你目前没有性能问题，编写可维护的代码更重要的IMO。 – ken2k

然后让交易在数据库中打开的时间更长吗？并可能导致数据库锁争用？ –

你有几个选择。

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

存储过程是过去的路，主要是由于性能。但是，随着近期SQL Server实现中对动态查询的性能优化的改进，这已经不再成为问题（尽管在某些边缘情况下仍然可能有小优势）。性能不再是一个优势，将逻辑集中在代码和其他业务逻辑中变得越来越有意义。

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

使用实体框架（或任何ORM）可以更容易地实现工作单元，但是如果您致力于使用ADO.NET而不使用ORM，则有办法做到这一点。 This article给出了实现UoW w/ADO.NET的相当不错的概述。

来源

2013-11-21 14:26:34

其实，我正在使用Dapper（microDAL）。我发现它更不像我的数据库结构...更抽象。所以如果我在数据库中进行更改，我不必部署新版本（具有更新的实体结构）。存储过程使其更加抽象，所以我仍然不明白为什么不使用它们:) –

看起来你可以实现UoW w/Dapper。查看[Github自述文件]（https://github.com/Pencroff/Dapper-DAL），其中介绍了使用Unit of Work w/IoC。 –

关于使用存储过程，抽象是一个抽象，不管它存在于哪一层。如果你的查询逻辑抽象到一个存储库或其他服务层，你仍然有抽象，但在C＃代码而不是SQL中，它与你的其他逻辑一起生活。就我个人而言，我发现在SQL和C＃中都有逻辑是很麻烦的。管理w /源代码控制也更容易一些。 –

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

回答

相关问题