Абстракцию вроде не очень любят, поэтому начну с конкретики.

Есть такая штука как ContextFactory (заголовок Using a DbContext factory)

https://learn.microsoft.com/en-us/ef/core/dbcontext-config...

Varaint 1

public class MyDbRepository: IMyDbRepository
{
    private readonly IDbContextFactory<ApplicationDbContext> _contextFactory;
    public MyController(IDbContextFactory<ApplicationDbContext> contextFactory)
    {
        _contextFactory = contextFactory;
    }
    public void DoSomething()
    {
        using (var context = _contextFactory.CreateDbContext())
        {
            // ...
        }
    }
}

Variant 2

public class MyDbRepository: IMyDbRepository
{
    private readonly ApplicationDbContext _context;
    public MyController(ApplicationDbContext context)
    {
        _context = context;
    }
    public void DoSomething()
    {
        {
            // use _context...
        }
    }
}
...application part....
IMyDbRepository repo= 'over DI';
using(ApplicationDbContext  context = GetContextFromFacroty())
{
   repo.Dosomething
}

В варинте 1 свобода на уровне репозитория. В варинте 2 - свобода на уровне приложения.

Что выбираем и почему?

Что выбираем и почему?

-----

По задаче.

Статический коннект к базе - достаточно просто DbContext.

Динамическое переключение между хранилищами - будь любезен слепить фабрику контекстов.

И это... проверь код - инициация вне конструктора работать не должна.

Динамическое переключение между хранилищами

не надо

проверь код

какой именно? То что я написал, просто так для понимания проблемы, хотя и там ошибки не вижу. инициация вне конструктора работать не должна - конкретнее мона?

не надо

-----

Значит фабрика - лишнее.

конкретнее мона?

-----

class MyDbRepository

public MyController(ApplicationDbContext context)

readonly не должно инициироваться в методе

Что выбираем и почему?

Выбираем 1-й вариант, т.к. только он дает гарантию контроля (выспобождения) ресурсов.

Ну и во 2-ом примере у тебя ошибка. Должно быть так:

...application part....
using(ApplicationDbContext  context = GetContextFromFacroty())
{
   IMyDbRepository repo = new MyDbRepository(context);
   repo.Dosomething
}

только он дает гарантию контроля (выспобождения) ресурсов

А почему 2й этого не даёт? И как будем тестить "свободу", что получаем в 1м методе

Ну и во 2-ом примере у тебя ошибка. Должно быть так

странно, и для 8й версии?

https://learn.microsoft.com/en-us/dotnet/csharp/language-r...

readonly не должно инициироваться в методе

даже и не заметил , просто скопипастил 1 вариант.

А почему 2й этого не даёт?

Потому что ты не можешь гарантировать и контролировать, что вызывающий тебя код в конце работы вызывает Dispose.

И как будем тестить "свободу", что получаем в 1м методе

В вервом методе освобождение ресурсов под контролем репозитория, освобождение контекста можно протестировать юнит тестом.

странно, и для 8й версии?

Не совсем понимаю, что ты хочешь узнать :)

Создаваемые контекст нужно как-то передать в репозиторий.

Только что заметил, что у класса репозитория нет конструктора. Зато есть какой-то конструктор для класса MyController... Предполагаю, что конструктор должен называться MyDbRepository, а не MyController.

вызывает Dispose

Dispose чего - contextFactory?

Так я его не создаю явно DI всё делает за меня

В вервом методе освобождение ресурсов под контролем репозитория

дело не в этом, метод может возвращать IAsyncEnumerable<X> или IQueryable<X> и с результатом можно делать что хошь - Это я и называю свобода.

Не совсем понимаю, что ты хочешь узнать

Будет ли ошибка для 8й версии шарпа?

Предполагаю, что конструктор

Совершенно правильно, но поправить позже 1й пост низзя, а код я совершенно не проверял, меня интересовало только донести идею разницы.

Dispose чего - contextFactory?
Так я его не создаю явно DI всё делает за меня

Ты берешь context явным образом из фабрики. Посмотри свой код в 1ом посте.

Будет ли ошибка для 8й версии шарпа?

При чем тут версия шарпа?

Посмотри свой код:

public class MyDbRepository: IMyDbRepository
{
    private readonly ApplicationDbContext _context;
    public MyController(ApplicationDbContext context)
    {
        _context = context;
    }
    public void DoSomething()
    {
        {
            // use _context...
        }
    }
}
...application part....
IMyDbRepository repo= 'over DI'; <<-- тут ты получаешь объект типа IMyDbRepository
using(ApplicationDbContext  context = GetContextFromFacroty()) <<-- а тут ты получаешь контекст, который надо передать в конструктор строчкой выше.
{
   repo.Dosomething
}

Очевидно, что такая конструкция не будет работать ни в какой версии шарпа. Или в 8й версии что-то поменяли?

Посмотри свой код в 1ом посте.

Да, наконец-то посмотрел. У меня перед глазами код из проекта был, как картинка. Но срисовал неправильно

Там не так должно быть, что то думал что так написано. И это не понравилось, сорри.

using ApplicationDbContext  context = GetContextFromFacroty();

Использование следующее

using(IMyDbRepository repo = CreateRepository()) 
{
   repo.Dosomething();
}

Dispose чего - contextFactory?

------

DbContext или производного от него. Мелкомягкие отдельно апойнтят необходимость вызова деструктора кодом, а не GC.

Спросите у ChatGPT. Из-за этого чата можно работу потерять в будущем, чат умеет хорошо помогать программировать см.:

Пишит сценарий:

Если я кому-то отвечаю, это не значит что я ему симпатизирую, каждый остаётся при своём мнении Meine Die Formel der Liebe

Спросите у ChatGPT. Из-за этого чата можно работу потерять в будущем, чат умеет хорошо помогать программировать см.:

Он умеет тырить куски готового кода, иногда смешивая их до полного неиспользования. И эти игрушки маленькие, которые он выдаёт, это зачастую цельнотянутые проекты с чужих репозиториев. Короче, ничего нового он не придумывает, а лишь копирует и комбинирует уже известное. Причём тупо копировать у него получается на порядок лучше, а если надо скомбинировать, то там всё перепроверять надо, чтобы чушь не вышла. Т.е. даже эта раскрученная херня работает лишь как поисковая машина и плохой джун, который даже куски готового кода не всегда соединить может.

ну так и там и там это выполняется

Спросите у ChatGPT.

И где? Раз попалось без регистрации, но теперь не работает.

Из-за этого чата можно работу потерять в будущем

Конкретный пример работы можно, из сферы программирования?

Из-за этого чата можно работу потерять в будущем

Конкретный пример работы можно, из сферы программирования?

Копипастер. Но сам этот чат в ваш проект ничего вставлять не умеет, и готовых инструментов для внедрения копипасты в ваши проекты тоже нет. Поэтому даже для копипасты пока ещё нужен живой чел.

- За что я плачу тебе 101 тысячу в год?

- 1 тысячу за то, что копипастю, и 100 тысяч за то, что знаю, куда скопипастить.

Копипастер.

Пока не встречал исключительно енто. И не могу представить это для нормального проекта.