Zanim omówimy czym jest IoC i jak będę go używał, zacznijmy od tego czym jest Dependency Injection. Głównie chodzi o to, żeby rozdzielić implementacje poszczególnych klas. Załóżmy, że mamy taki kod:

class A {...}
    
class B
{
    private A myA;
    public B()
    {
        myA = new A();
    }
}

Nasza klasa B jest w pełni zależna od klasy A. Lepszym rozwiązaniem byłoby napisać interfejs IA, który będzie zawierał sygnaturę publicznych metod A (dlaczego jeszcze warto używać interfejsów?) i A będzie go implementowało. Dzięki temu, jeśli kiedyś stwierdzimy, że chcemy inną implementację IA, będziemy mogli ją bez problemu utworzyć. Natomiast klasa B potrzebuje jedynie informacji o interfejsie IA, a nie o jego implementacji.

No dobra, ale gdzie tu jest Dependency Injection? Otóż to wstrzykiwanie zależności polega na tym, że przekazujemy obiekt implementujący IA do konstruktora B i ten nie musi się martwić tworzeniem nowego obiektu.

Otrzymujemy coś takiego:

interface IA {...}
class A {...}
    
class B
{
    private IA myIA;
    public B(IA iA)
    {
        myIA = iA;
    }
}

Następnie w kodzie naszej aplikacji wywołamy

var b = new B(new A); //lub inna implementacja

I na tym głównie polega DI. Korzyści z niego płynące są bardziej widoczne przy dużych projektach, ale warto stosować to również w mniejszych projektach, aby zrobić sobie właściwe nawyki.