TransactionScope事务=新的TransactionScope() VS TransactionScope s= context.Connection.BeginTransaction()

Question

我只想知道，如果事务未完成，我是否要回滚数据库中的所有更改？

 using (TransactionScope transaction = new TransactionScope())

和

using (var dbContextTransaction = context.Database.BeginTransaction())

我在阅读这两篇文章时感到困惑：

Connection.BeginTransaction和实体框架4？

和

https://learn.microsoft.com/en-us/ef/ef6/saving/transactions

**注意，如果有必要，我在项目中使用实体框架4。

Answer 1

而数据库。BeginTransaction()仅用于与数据库相关的操作、事务、系统。事务。TransactionScope，用于在事务中将db操作和C#代码混合在一起。

请参阅下面的Links.Hope，它们帮助您：

LINQ中的TransactionScope与事务

Database.BeginTransaction对Transactions.TransactionScope

Answer 2

来自编写Microsoft 2012的程序

在显式事务中有许多痛点。第一个困难在于，每个用于在事务中执行更新的SqlCommand对象都必须将其事务属性设置为BeginTransaction返回的SqlTransaction对象。这意味着您必须小心地将SqlTransaction对象传递到代码中执行更新的任何位置，因为未能将其分配给事务中每个SqlCommand对象的Transaction属性将导致运行时异常。当您需要在执行更新的多个方法调用中跟踪SqlTransaction对象时，这个问题就更加复杂了。当这些方法需要足够的灵活性来工作时，不管是否涉及或需要事务，管理事情就变得更加困难。 当我们在后面讨论的任何其他技术提供原始对象的抽象层时，问题就更严重了。例如，由于SqlDataAdapter实际上包装了三个不同的SqlCommand对象(用于插入、更新和删除)，因此必须在数据适配器下面挖掘，并将其挂钩到其三个底层命令对象中，以便设置它们的Transaction属性。(我们通常不建议在应用程序中混合和匹配不同的数据访问API，但如果必须跨技术组合对更新进行事务处理，则隐式事务可以简化。) TransactionScope对象是2005年在.NET 2.0中作为专用事务管理API的一部分引入的，它允许您隐式编码事务。这是一种很好的方法，可以减轻与显式事务相关的所有上述负担。因此，这里的指导是尽可能地处理隐式事务。当允许框架为您处理事务管理时，您将编写更少的更灵活的代码。但是，理解与SqlTransaction对象的显式事务仍然很重要，因为您可能需要集成和扩展已经使用显式事务的现有代码。因此，我们将涵盖这两种事务管理风格，以便为所有情况做好准备。 除了隐式事务之外，事务管理API还提供了更多的好处。例如，如果更新涉及跨多个数据库的更改，TransactionScope能够自动将轻量级事务(与单个数据库关联的事务)提升到分布式事务。

Answer 3

您应该注意到TransactionScope存在两个缺陷。

首先，默认情况下，它将创建一个带有SERIALIZABLE隔离级别的事务，对于Server来说，这是一个糟糕的选择。因此，您应该始终像这样创建TransactionScope：

public class TransactionUtils 
{
  public static TransactionScope CreateTransactionScope()
  {
    var transactionOptions = new TransactionOptions();
    transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;
    transactionOptions.Timeout = TransactionManager.MaximumTimeout;
    return new TransactionScope(TransactionScopeOption.Required, transactionOptions);
  }
}

见“咆哮”：使用被认为有害的新TransactionScope()

第二，TransactionScope支持分布式事务。因此，它将使您能够在单个事务中登记不同的连接，甚至不同的资源提供程序。虽然这偶尔是有用的，但它更多的是一个陷阱。如果您意外地得到了一个分布式事务，您可能会意外地依赖于在您的环境中有一个分布式事务协调器。因此，您应该采取步骤避免具有分布式事务，例如关闭开发环境中的Microsoft分布式事务协调器(MSDTC)。并确保无论何时在事务中登记多个方法，它们都不会同时打开SqlConnection。