public MyClass
{
    public MyClass(ILogger<MyClass> logger) { ... }
}

public MyOtherClass
{
    public MyOtherClass(MyClass x) { ... }
}

public BankingService: IBankingService
{
  public BankingService(IDeliveryService deliveryService){...}
  ...
}
...
public DeliveryService: IDeliveryService
{
  public DeliveryService(IBankingService) {...}
  ...
}

DbConnection conn1 = (DbConnection)container.resolve("adminDbConnection");
DbConnection conn2 = (DbConnection)container.resolve("userDbConnection");

var dbOptions = new DbOptions()
    .UseSqlServer(Configuration.GetConnectionString("DefaultConnection"));
var dbContext = new DbContext(dbOptions);
var mainService = new MainService(dbContext);
services.AddHostedService(mainService);

class Foo
{
    public Foo(Bar b)
    {
        if (!b.IsValid)
            throw ...
    }
}

МП>    var a = new A(12, "6")
МП>    {
МП>        Field1 = new B(),
МП>        Field2 = C.Instance;
МП>    }
МП>

class Service
{
    public Service(IDependency1 dependency1, IDependency2 dependency2)
    {
    }

    public void DoSomeWork()
    {
        //...
    }
}

if(A) then add(DeliveryService)
if(B) then add(PigeonTransportService)

var mainService = new MainService(new InMemoryProvider());
...
testThis(mainService);
testThat(mainService);

    var a = new A(12, "6")
    {
        Field1 = new B(),
        Field2 = C.Instance;
    }

DI directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies

# production

cotainer = AppContainter()
app = container.create_app()
app.run()

# test code

cotainer = AppContainter()
service1 = Stub()
service2 = Mock()

container.override(dep1=service1, dep2=service2)

app = container.create_app()
app.run()

# production

class AppRoot:
  method create_service1()
  method create_service2()
  method create_app()

app = AppRoot().create_app()
app.run()

# test code

class TestAppRoot(inherit AppRoot):
  method create_service1() - return Stub
  method create_service2() - return Mock

app = TestAppRoot().create_app()
app.run()

1. Помечаем C как "under construction"
   
2. Смотрим, как его вообще можно создать.
   
3. Видим, что нужно B
   
4. Видим, что B у нас еще нет
   
5. Рекурсивно выполняем этот же алгоритм
   
6. Создаем C
   
7. Успешно заносим C в реестр

Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.

var instance = serviceProvider.Get<SomeObject>()

var db = new DbContext();
var config = new AppConfig();
var instance = new SomeObject(db, config);

этот код показывает, что ты ни разу правильно не написал тестового кода с использованием DI, правильно было бы так:
Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо

Container.Register<InMemoryProvider, IDbProvider> (); // и 5 других зависимостей мне трогать не надо
var mainService = Container.Resolve<MainService> ();

T>>>т.е. ты делаешь DI без интерфейсов? ты точно свою ссылку из википедии прочитал?

Б># production

Б>class AppRoot:
Б>  method create_service1()
Б>  method create_service2()
Б>  method create_app()
Б>

new AppRoot(new RealDb(), new RealFilesystem(), new SystemClock()...).run();

new AppRoot(new MockDb(), new MockFilesystem(), new MockClock()...).run();