在Entity Framework中使用TransactionScope查询是个好主意吗？

Question

我一直在阅读Microsoft的模式和实践组(高度可扩展的解决方案的数据访问:使用SQL,NoSQL和Polyglot持久性)中的文档.

在第3章的"从SQL Server数据库中检索数据"一节中,作者讨论了使用Entity Framework从数据库加载实体.这是他们的示例代码:

using (var context = new PersonContext())
{
    Person person = null;

    using (var transactionScope = this.GetTransactionScope())
    {
        person = context.Persons
            .Include(p => p.Addresses)
            .Include(p => p.CreditCards)
            .Include(p => p.EmailAddresses)
            .Include(p => p.Password)
            .SingleOrDefault(p => p.BusinessEntityId == personId);

        transactionScope.Complete();
    }

    // etc...
}

请注意通过该GetTransactionScope方法使用自定义事务范围,在其基本上下文类中实现,如下所示:

public abstract class BaseRepository
{
    private static TransactionOptions transactionOptions = new TransactionOptions()
    {
        IsolationLevel = IsolationLevel.ReadCommitted
    };

    protected virtual TransactionScope GetTransactionScope()
    {
        return new TransactionScope(TransactionScopeOption.Required, transactionOptions);
    }
}

在MSDN上使用事务(EF6 Onwards)状态:

在所有版本的Entity Framework中,无论何时执行SaveChanges()以在数据库上插入,更新或删除,框架都会将该操作包装在事务中[...]事务的隔离级别是数据库提供程序考虑的任何隔离级别它的默认设置.默认情况下,例如,在SQL Server上,这是READ COMMITTED.实体框架不会在事务中包装查询.此默认功能适用于许多用户

大胆的重点是我的.

我的问题:在使用Entity Framework时,使用如上所示的TransactionScope是否过度,特别是对于数据读取？

(我在发帖后意识到这个问题的答案可能有点基于意见,抱歉.)

Answer 1

这个问题有点开放.但可能对于学习脏读的人有用.隔离和EF.你已经阅读了EF Transaction Scope ef6,我们有一个明确的问题.

通常我会说让EF管理范围.初学者不考虑未提交的读取,它是EF的一个很好的默认值.

您可能有正当理由想要控制范围.或者需要使用现有的交易.但仍然需要专家使用.

所以现在真正的问题.
将这种防御性编程包含在隔离中是一种好习惯.

我的观点:
只有它不会使代码难以维护,并且难以重用.

Oracle和SQL服务器具有默认的Read Committed.我希望其他数据库也是如此.因此我会得出结论,很可能是必要的保护增加了复杂性.
我不会把它添加到我的代码中.