EF Core 2.0学习

分手后的思念是犯贱 2021-06-26 16:06 372阅读 0赞

# 日志记录 #

## ASP.NET Core 应用程序 ##

一旦使用了 `AddDbContext` 或 `AddDbContextPool` ，EF Core 就会自动集成 ASP.NET Core 的日志记录机制。因此，当使用 ASP.NET Core 的时候，日志记录的配置与 [ASP.NET Core 帮助文档][ASP.NET Core] 中所描述的是一致的。

## 其他应用程序 ##

EF Core 日志记录目前需要一个 `ILoggerFactory`，其自身配置了一个或多个 `ILoggerProvider`。通用提供程序是随以下程序包一起发布的：

*  [Microsoft.Extensions.Logging.Console][]：简单的控制台日志记录器。
 *  [Microsoft.Extensions.Logging.AzureAppServices][]：支持 Azure 应用程序服务的 “诊断日志” 和 “日志流” 功能。
 *  [Microsoft.Extensions.Logging.Debug][]：使用 System.Diagnostics.Debug.WriteLine() 将日志记录到调试监视器。
 *  [Microsoft.Extensions.Logging.EventLog][]：记录到 Windows 事件日志。
 *  [Microsoft.Extensions.Logging.EventSource][]：支持 EventSource/EventListener。
 *  [Microsoft.Extensions.Logging.TraceSource][]：使用 System.Diagnostics.TraceSource.TraceEvent() 将日志记录到跟踪监视器。

安装合适的程序包后，应用程序应该创建单一的/全局的 LoggerFactory 实例。例如，使用控制台记录日志：

public static readonly LoggerFactory MyLoggerFactory = new LoggerFactory(new[] { new ConsoleLoggerProvider((_,__) => true,true)});

然后这个单一的/全局的实例应该通过 `DbContextOptionsBuilder` 注册到 EF Core。例如：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseLoggerFactory(MyLoggerFactory) // 不要每次都创建新的 ILoggerFactory 实例
            .UseSqlServer(
                @"Server=(localdb)\mssqllocaldb;Database=EFLogging;Trusted_Connection=True;ConnectRetryCount=0");

> 警告
> 
> 应用程序应该避免为每个上下文实例都创建新的 ILoggerFactory 实例，这很重要。否则会导致内存泄露、性能低下。

## 日志过滤 ##

最简单的日志过滤方法就是在注册 `ILoggerProvider` 的时候对其进行配置。例如：

public static readonly LoggerFactory MyLoggerFactory
        = new LoggerFactory(new[]
        { 
            new ConsoleLoggerProvider((category, level)
                => category == DbLoggerCategory.Database.Command.Name
                   && level == LogLevel.Information, true)
        });

在该样例中，过滤后的日志仅包含这样的信息：

*  属于 `Microsoft.EntityFrameworkCore.Database.Command` 分类的
 *  等级为 `Information` 的

对于 EF Core，日志记录器分类是在 `DbLoggerCategory` 类型中定义的，主要是为了便于查找分类，但是都解析为简单字符串。

关于底层日志基础设施的详细内容请查看 [ASP.NET Core 日志帮助文档][ASP.NET Core 1]。

--------------------

# 弹性链接 #

弹性链接会在数据库命令失败时自动重试。通过提供封装了故障检测和命令重试所需逻辑的“执行策略”,该功能可以应用于任何数据库。EF Core 提供程序能够根据特定的数据库故障条件和最优重试策略来提供执行策略。

比如说，SQL Server 提供程序包含一个特定的针对 SQL Server（包括 SQL Azure）的执行策略。它很清楚可以被重试的异常类型、具有合理的默认最大尝试次数、合理的两次重试之间的默认延迟等等。

在为上下文实例配置相关选项的时候就可以指定一个执行策略。这通常是在你派生上下文的 `OnConfiguring` 方法中完成，对于 ASP.NET Core 应用程序则在 `Startup.cs` 中完成。

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    { 
        optionsBuilder
            .UseSqlServer(
                @"Server=(localdb)\mssqllocaldb;Database=EFMiscellanous.ConnectionResiliency;Trusted_Connection=True;",
                options => options.EnableRetryOnFailure());
    }

## 自定义执行策略 ##

这里提供了自定义执行策略的注册机制，如果你想要更改默认的策略，就可以使用它。

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    { 
        optionsBuilder
            .UseMyProvider(
                "<connection string>",
                options => options.ExecutionStrategy(...));
    }

## 执行策略与事务 ##

发生错误时自动重试的策略要能够在失败的重试业务块中回放每一个操作。当启用重试时，通过 EF Core 执行的每个操作自身也会成为可重试的操作，也就是说，当发生瞬时错误时每个查询以及每各 `SaveChanges()` 调用都将被作为一个单元被重试。

然而，如果你的代码使用 `BeginTransaction()` 初始化了事务，就意味着你自己定义了要被作为一个单元的一组操作，也就是说发生错误时事务中的一切都需要被回放。如果你在使用了执行策略的情况下这样做，你将收到如下异常信息。

> InvaliOperationException：The configured execution strategy ‘SqlServerRetryingExecutionStrategy’ does not support user initiated transactions. Use the execution strategy returned by ‘DbContext.Database.CreateExecutionStrategy()’ to execute all the operations in the transaction as a retriable unit.

大概意思就是配置的执行策略 “`SqlServerRetryingExecutionStrategy`” 不支持用户初始化的事务。使用 “`DbContext.Database.CreateExecutionStrategy()`” 返回的执行策略可以将事务中的所有操作作为可重试单元来执行。

解决方案会用一个表示所有需要被执行操作的委托来手动调用执行策略。如果发生了瞬时故障，执行策略会再次调用该委托。

using (var db = new BloggingContext())
    { 
        var strategy = db.Database.CreateExecutionStrategy();
    
        strategy.Execute(() =>
        { 
            using (var context = new BloggingContext())
            { 
                using (var transaction = context.Database.BeginTransaction())
                { 
                    context.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/dotnet"});
                    context.SaveChanges();
    
                    context.Blogs.Add(new Blog { Url = "http://blogs.msdn.com/visualstudio"});
                    context.SaveChanges();
    
                    transaction.Commit();
                }
            }
        });
    }

## 事务提交失败和[幂等][Link 1]性问题 ##

通常在出现连接错误时当前事务就会回滚。然而，事务提交时连接失败是无法知道事务的结果状态的。详细信息请参阅 [blog post][]。

默认情况下，执行策略将会根据事务是否回滚而重新尝试操作。但是，如果新数据库状态不兼容就会导致异常；而如果操作不依赖于某个特定状态就可能导致 **数据损坏**，比如说使用自动生成主键值的方式插入新的数据行。

有一些方法可以处理这种情况。

### 选项1 - （几乎）不做任何处理 ###

在事务提交过程中出现连接失败的可能性很低，因此，如果发生该情况，仅仅让应用程序失败是可接受的。

但是，你需要避免使用存储方生成主键值的方式，如此以确保能够抛出异常，而不是添加重复行。建议使用客户端生成的 GUID 值或者客户端值生成器。

### 选项3 - 重建应用程序状态 ###

1.  放弃当前 `DbContext`。
2.  创建新的 `DbContext` 并从数据库还原应用程序状态。
3.  通知用户最近的操作可能没有成功完成。

### 选项3 - 添加状态验证 ###

对于大部分更改数据库状态的操作，添加用于验证操作是否成功的代码是可能的。使用 EF 提供的扩展方法可以轻松实现 - `IExecutionStrategy.ExecuteInTransaction`。

该方法会开启和提交一个事务，其 `VerifySucceeded` 参数接受一个方法，这个方法会在事务提交发生瞬时错误时被调用。

using (var db = new BloggingContext())
    { 
        var strategy = db.Database.CreateExecutionStrategy();
    
        var blogToAdd = new Blog { Url = "http://blogs.msdn.com/dotnet"};
        db.Blogs.Add(blogToAdd);
    
        strategy.ExecuteInTransaction(db,
            operation: context =>
            { 
                context.SaveChanges(acceptAllChangesOnSuccess: false);
            },
            verifySucceeded: context => context.Blogs.AsNoTracking().Any(b => b.BlogId == blogToAdd.BlogId));
    
        db.ChangeTracker.AcceptAllChanges();
    }

> 注意
> 
> 这里调用 `SaveChanges` 时将参数 `acceptAllChangesOnSuccess` 设置为 `false`，如此以在 `SaveChanges` 成功时避免更改 `Blog` 实体的状态为 `Unchanged`。这就允许在提交失败并且事务回滚时重新尝试相同的操作。

### 选项4 - 手动跟踪事务 ###

如果你需要使用存储方生成主键值，或者需要一个处理不依赖于操作执行的提交失败的常规方式，那么可以在提交失败时为每个被跟踪的事务指定一个ID。

1.  向数据库添加一个表，用来跟踪事务的状态。
2.  在每个事务执行前向该表插入一行数据。
3.  如果在提交过程中连接失败，检查数据库中相应的行是否存在。
4.  如果提交成功，删除对应的行以避免表数据量无线增长。

using (var db = new BloggingContext())
    { 
        var strategy = db.Database.CreateExecutionStrategy();
    
        db.Blogs.Add(new Blog {  Url = "http://blogs.msdn.com/dotnet" });
    
        var transaction = new TransactionRow { Id = Guid.NewGuid()};
        db.Transactions.Add(transaction);
    
        strategy.ExecuteInTransaction(db,
            operation: context =>
            { 
                context.SaveChanges(acceptAllChangesOnSuccess: false);
            },
            verifySucceeded: context => context.Transactions.AsNoTracking().Any(t => t.Id == transaction.Id));
    
        db.ChangeTracker.AcceptAllChanges();
        db.Transactions.Remove(transaction);
        db.SaveChanges();
    }

> 注意
> 
> 请确保用于验证的上下文实例定义了执行策略，因为其可能在验证期间再次连接失败（如果其在事务提交过程中失败）。

--------------------

# 配置 `DbContext` #

本文展示的是使用 `DbContextOptions` 配置 `DbContext` 的模式。选项集（Options）主要是用来选择和配置数据存储的。

## 配置 `DbContextOptions` ##

`DbContext` 必须具有一个 `DbContextOptions` 的实例才能执行。这可以通过重写 `OnConfiguring` 来配置，或者通过构造方法参数由外部提供。

如果同时使用了两种方式，`OnConfiguring` 会基于已提供的选项集（options）被执行，这意味着 `OnConfiguring` 是成了附加的过程，可以在其中重写由构造方法参数获取的选项集。

### 构造方法参数 ###

带构造方法的上下文类型代码:

public class BloggingContext : DbContext
    { 
        public BloggingContext(DbContextOptions<BloggingContext> options)
            : base(options)
        {  }
    
        public DbSet<Blog> Blogs {  get; set; }
    }

> 提示
> 
> DbContext 的基础构造方法还接受非泛型版本的 `DbContextOptions`。对于具有多个上下文类型的应用程序，不建议使用该非泛型版本。

从构造方法参数初始化上下文实例的应用程序代码:

var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
    optionsBuilder.UseSqlite("Data Source=blog.db");
    
    using (var context = new BloggingContext(optionsBuilder.Options))
    { 
      // 业务代码
    }

> 警告
> 
> `OnConfiguring` 比较迟被调用，因此可以在其中覆盖从DI或构造函数获得的选项值。该方法不适合用来测试（除非指向完整的数据库）。

带 `OnConfiguring` 的上下文类型代码：

public class BloggingContext : DbContext
    { 
        public DbSet<Blog> Blogs {  get; set; }
    
        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        { 
            optionsBuilder.UseSqlite("Data Source=blog.db");
        }
    }

从初始化上下文实例的应用程序代码:

using (var context = new BloggingContext())
    { 
      // 业务代码
    }

## 通过依赖注入使用 `DbContext` ##

EF 支持通过依赖注入容器来使用 `DbContext`。可以使用 `AddDbContext<TContext>` 将你的 DbContext 类型添加到服务容器。

`AddDbContext` 将使得 DbContext 类型、`TContext` 以及 `DbContextOptions<TContext>` 都可以从服务容器注入获得。

查看后面的 阅读更多 可以深入了解依赖注入。

将 `DbConext` 添加到依赖注入：

public void ConfigureServices(IServiceCollection services)
    { 
        services.AddDbContext<BloggingContext>(options => options.UseSqlite("Data Source=blog.db"));
    }

这需要向 `DbContext` 类型中添加接受 `DbContextOptions` 类型的参数的构造方法。

上下文类型：

public class BloggingContext : DbContext
    { 
        public BloggingContext(DbContextOptions<BloggingContext> options)
          :base(options)
        {  }
    
        public DbSet<Blog> Blogs {  get; set; }
    }

（ASP.NET Core 中的）应用程序代码：

public MyController(BloggingContext context)

（直接使用 ServiceProvider 的）应用程序代码：

using (var context = serviceProvider.GetService<BloggingContext>())
    { 
      // do stuff
    }
    
    var options = serviceProvider.GetService<DbContextOptions<BloggingContext>>();

## 使用 `IDesignTimeDbContextFactory<TContext>` ##

作为上述选项的替代，你还可以提供一个 `IDesignTimeDbContextFactory<TContext>` 的实现。EF 工具集能够使用该工厂来创建 `DbContext` 的实例。这可能是实现设计时特定的体验的要求，比如说数据迁移。

实现这个接口能够为没有公共默认构造方法的上下文类型启用设计时服务。设计时服务将自动发现与上下文实例同一程序集的该接口的实现。

例如：

using Microsoft.EntityFrameworkCore;
    using Microsoft.EntityFrameworkCore.Infrastructure;
    
    namespace MyProject
    { 
        public class BloggingContextFactory : IDesignTimeDbContextFactory<BloggingContext>
        { 
            public BloggingContext CreateDbContext(string[] args)
            { 
                var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
                optionsBuilder.UseSqlite("Data Source=blog.db");
    
                return new BloggingContext(optionsBuilder.Options);
            }
        }
    }

[ASP.NET Core]: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging?tabs=aspnetcore2x
[Microsoft.Extensions.Logging.Console]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.Console/
[Microsoft.Extensions.Logging.AzureAppServices]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.AzureAppServices/
[Microsoft.Extensions.Logging.Debug]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.Debug/
[Microsoft.Extensions.Logging.EventLog]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.EventLog/
[Microsoft.Extensions.Logging.EventSource]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.EventSource/
[Microsoft.Extensions.Logging.TraceSource]: https://www.nuget.org/packages/Microsoft.Extensions.Logging.TraceSource/
[ASP.NET Core 1]: https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/logging?tabs=aspnetcore2x
[Link 1]: https://baike.baidu.com/item/%E5%B9%82%E7%AD%89/8600688?fr=aladdin
[blog post]: http://blogs.msdn.com/b/adonet/archive/2013/03/11/sql-database-connectivity-and-the-idempotency-issue.aspx