DbContext未配置数据库提供程序问题及双配置方式疑问

一、最初报错的根源 #

你在BaseRepository的无参构造函数里直接new TourDBContext()：

public BaseRepository()
{
    this.context = new TourDBContext();
}

这种方式完全绕开了依赖注入（DI）容器中通过AddDbContext配置好的上下文实例，调用的是TourDBContext的无参构造函数——此时DbContext没有获取到任何数据库提供程序的配置信息，自然会抛出"未为此DbContext配置数据库提供程序"的错误。

二、添加OnConfiguring后错误消失的原因 #

你加的OnConfiguring方法里有个核心判断：if (!optionsBuilder.IsConfigured)，只有当DbContext未被配置时，才会读取本地配置文件设置数据库连接和跟踪行为。当你直接new TourDBContext()时，optionsBuilder.IsConfigured为false，这段配置逻辑就会执行，DbContext能拿到数据库提供程序信息，错误也就消失了。

三、同时用OnConfiguring和AddDbContext的影响 #

1. 优先级规则 #

• 当通过DI容器（也就是AddDbContext注册的方式）创建TourDBContext实例时，DI会传入已经配置好的DbContextOptions<TourDBContext>，此时optionsBuilder.IsConfigured为true，OnConfiguring里的自定义配置逻辑不会执行。简单说：DI容器的配置优先级高于OnConfiguring中的默认配置。
• 只有当你直接调用无参构造函数（比如new TourDBContext()）创建实例时，OnConfiguring里的配置才会生效。

2. 潜在问题 #

• 配置不一致风险：你在Program.cs里用的连接字符串key是TourDBConnectionString，但OnConfiguring里是TravelDBConnectionString，两处配置不统一，后续维护很容易出问题。
• 性能冗余：GetConnectionString方法每次都会重新构建IConfiguration实例，频繁调用会造成不必要的性能损耗。

3. 推荐实践 #

• 统一用DI容器管理TourDBContext，删掉BaseRepository的无参构造函数，改成构造函数注入：

  public class BaseRepository<T> where T : class
  {
      private readonly TourDBContext context;
  
      // 通过构造函数注入上下文
      public BaseRepository(TourDBContext context)
      {
          this.context = context;
      }
  
      public async Task<List<T>> GetAllAsync()
      {
          try
          {
              var list = await context.Set<T>().ToListAsync();
              return list;
          }
          catch (Exception ex)
          {
              throw new Exception(ex.Message);
          }
      }
  }
  

• 把仓储类也注册到DI容器：

  builder.Services.AddScoped<CategoryRepository>();
  

• 这种情况下可以删掉OnConfiguring里的配置逻辑，让DI容器统一管理DbContext配置，避免冗余和不一致问题。

内容的提问来源于stack exchange，提问作者Panda