Создать один ленивый и один нетерпеливый DbContext через наследование?

Решение

Все, что я хочу, - это иметь возможность использовать ленивый dbContext или нетерпеливый dbContext

У вас должна быть возможность просто установить конфигурацию в подклассах:

public class LazyContext : MyContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseLazyLoadingProxies();
    }
}

public class EagerContext : MyContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {

    }
}

Есть два варианта настройки конфигурации параметра db: через конструктор (и, следовательно, маршрут DI) или через сам класс. Поскольку этот конкретный параметр зависит от класса, и вы не хотите манипулировать им при регистрации DI, имеет смысл полагаться на метод конфигурации, зависящий от класса.

Почему ваше решение не сработало

Причина, по которой ваш первоначальный подход не сработал, заключается в том, что AddDbContext<T> регистрирует этот конкретный T как ваш тип зависимости. Из источника:

Метод расширения AddDbContext по умолчанию регистрирует типы DbContext с ограниченным временем существования.

Обратите внимание, что он регистрирует тип контекста, а не какие-либо интерфейсы / предки этого типа контекста.

Итак, когда вы это сделаете:

services.AddDbContext<LazyUserContext>((sp, opt) =>
{
    var connectionString = "very secret";
    opt.UseSqlServer(connectionString, x => x.CommandTimeout(300));
    opt.UseLazyLoadingProxies();
});

services.AddScoped<ILazyUserContext, LazyUserContext>();

Если ваш класс имеет зависимость типа ILazyUserContext, он слушает только вторую регистрацию, а Flatout игнорирует первую.

Только когда ваш класс имеет зависимость LazyUserContext, вы действительно получите параметры контекста db, которые вы указали при первой регистрации.

Обратите внимание, что вы можете использовать это поведение регистрации для конкретного типа в своих интересах, если хотите зарегистрировать реализацию по умолчанию:

// Specific interface => specific type
services.AddScoped<IUserContext, UserContext>();
services.AddScoped<ILazyUserContext, LazyUserContext>();

// General interface => explicitly chosen default type
services.AddScoped<IContext, UserContext>();

Это позволяет вам иметь некоторые классы, которые требуют особой нетерпеливой / ленивой загрузки, и другие классы, которые просто принимают то, что используется по умолчанию (которое может со временем измениться).

Проблема вызвана тем, что оба конструктора контекста используют (зависят от) один и тот же тип опций - DbContextOptions<UserContext>.

AddDbContext<TContext> фактически регистрирует два типа - сам контекст TContext, а также фабрику для зависимости опций контекста DbContextOptions<TContext>.

Итак, вы регистрируете две фабрики опций (вместе с действием конфигурации) - DbContextOptions<UserContext> и DbContextOptions<LazyUserContext>. Однако, как упоминалось в начале, LazyUserContext зависит от DbContextOptions<UserContext>, поэтому он просто создается с первой настройкой параметров, то есть точно так же, как и другие.

Это не относится к отложенной загрузке, но для любого сценария, который требует различных параметров (другой тип базы данных / строка подключения и т. Д.) И является причиной существования универсального класса DbContextOptions<TContext>.

Решение - изменить LazyUserContext зависимость

public LazyUserContext(DbContextOptions<LazyUserContext> options) : base(options) { }

и поскольку это не будет компилироваться, потому что база ожидает DbContextOptions<UserContext>, добавьте второй защищенный конструктор к базовому классу, принимающему только DbContextOptions

protected UserContext(DbContextOptions options) : base(options) { }