Wstrzykiwanie zależnoÅ›ci – Dependency Injection

utworzone przez Adam Jachocki | sty 19, 2022 | Architektura, Backend, junior, Programowanie

Wstęp

Ten artykuł opisuje czym jest dependency injection. A także jak z tego korzystać w .NET i po co. Jeśli wiesz, znasz, stosujesz, to raczej niczego nowego się tutaj nie dowiesz 🙂 On jest kierowany głównie do młodych programistów lub programistów nie znających tych mechanizmów.

O co chodzi we wstrzykiwaniu zależności?

Przede wszystkim musimy zdefiniować sobie zależność. O zależnoÅ›ci mówimy wtedy, kiedy jedna klasa zależy od drugiej. Weźmy sobie przykÅ‚adowÄ… klasÄ™ Writer, która umie wypisywać komunikaty i klasÄ™ Worker, która wykonuje jakÄ…Å› operacjÄ™ i posÅ‚uguje siÄ™ klasÄ… Writer.

class Writer
{
    public void Write(string message)
    {
        Console.WriteLine(message);
    }
}

class Worker
{
    Writer writer = new Writer();

    public void Foo()
    {
        writer.Write("Rozpoczynam pracÄ™...");
    }
}

Jak widzisz, klasa Worker zależy od klasy Writer.

Co wiÄ™cej, klasa Worker samodzielnie tworzy i używa obiekt klasy Writer. Takie coÅ› nazywamy silnym zwiÄ…zaniem (tight coupling). I chociaż tight coupling to pojÄ™cie szersze, to jednak dobrze jest prezentowany przez ten przykÅ‚ad. Dwie klasy sÄ… mocno ze sobÄ… zwiÄ…zane.

Takie zakodowane na sztywno zależności (silne związania) są złe dla aplikacji i powinieneś ich unikać. Dlaczego?

• jeÅ›li chciaÅ‚byÅ› aby komunikaty byÅ‚y wpisywane do pliku, a nie na konsolÄ™, musiaÅ‚byÅ› zmienić klasÄ™ Writer lub utworzyć nowÄ… i zmienić klasÄ™ Worker (sprzeczność z zasadÄ… OpenClose).
• jeÅ›li klasa Writer miaÅ‚aby inne zależnoÅ›ci, te zależnoÅ›ci musiaÅ‚by także zostać utworzone (lub w jakiÅ› sposób przekazane) przez klasÄ™ Worker. Lub utworzone w klasie Writer, co jeszcze bardziej zacieÅ›nia kod. Ponadto daje nam już zbyt dużo odpowiedzialnoÅ›ci (możliwa sprzeczność z zasadÄ… Single Responsibility) i zdecydowanie zaciemnia obraz.
• taka implementacja nie nadaje siÄ™ do testów jednostkowych

Te wszystkie problemy można rozwiÄ…zać stosujÄ…c wstrzykiwanie zależnoÅ›ci…

Siostro! Zastrzyk!

OK, teraz wyobraźmy sobie jak lepiej mogÅ‚aby wyglÄ…dać klasa Worker:

class Worker
{
    Writer writer;
    public Worker(Writer writer)
    {
        this.writer = writer;
    }

    public void Foo()
    {
        writer.Write("Rozpoczynam pracÄ™...");
    }
}

Spójrz, co siÄ™ staÅ‚o. WstrzyknÄ™liÅ›my obiekt klasy Writer do Worker za pomocÄ… konstruktora. Obiekt Writer w tym momencie jest już poprawnie stworzony (ma utworzone swoje wszystkie zależnoÅ›ci) i można go używać. Klasa Worker nie musi tworzyć już tego obiektu i nie daj Boże innych jego zależnoÅ›ci.

Po prostu Worker używa Writer. A skÄ…d go ma? To w zasadzie nie jest istotne. Czy Ciebie interesuje kto zrobiÅ‚ Ci przelew na konto? Czy ważne, że masz te pieniÄ…dze? 😉

Jednak caÅ‚y czas nie rozwiÄ…zaliÅ›my jednego problemu. Silnego zwiÄ…zania. Klasa Worker caÅ‚y czas jest silnie zwiÄ…zana z Writer. A gdyby tak posÅ‚użyć siÄ™ interfejsem?

interface IWriter
{
    void Write(string message);
}
class Writer: IWriter
{
    public void Write(string message)
    {
        Console.WriteLine(message);
    }
}

class Worker
{
    IWriter writer;
    public Worker(IWriter writer)
    {
        this.writer = writer;
    }

    public void Foo()
    {
        writer.Write("Rozpoczynam pracÄ™...");
    }
}

Na poczÄ…tku zdefiniowaliÅ›my sobie interfejs IWriter – z jednÄ… metodÄ…. Potem utworzyliÅ›my klasÄ™ Writer implementujÄ…cÄ… ten interfejs i na koniec do klasy Worker wstrzyknÄ™liÅ›my interfejs.

W .NET można wstrzykiwać zależności przez konstruktor (najczęściej używane), właściwość (częściej używane w Blazor, gdzie to jest jedyna możliwość w komponencie będącym widokiem), a nawet przez parametr (stosowane raczej w kontrolerze webowej aplikacji)

To nam rozwiÄ…zuje ostatni problem. Dlaczego? Bo możemy sobie teraz rozszerzyć naszÄ… aplikacjÄ™, piszÄ…c nieco innÄ… implementacjÄ™ klasy Writer:

class FileWriter : IWriter
{
    public void Write(string message)
    {
        File.AppendText(message);
    }
}

Teraz klasa Worker może dostać obiekt Writer lub FileWriter. Nie ma już silnego zwiÄ…zania z klasÄ… Writer. OtrzymaliÅ›my luźne powiÄ…zanie (loose coupling). Daje to też możliwość napisania oszukanej klasy (Fake), którÄ… można wykorzystać później w testach automatycznych:

class FakeWriter : IWriter
{
    public void Write(string message)
    {
        //żadnego ciała albo Debug.WriteLine
    }
}

Powyższy przykÅ‚ad pokazuje również wzorzec projektowy „Strategia”. Wzorzec ten jest poniekÄ…d jednym z przykÅ‚adów wstrzykiwania zależnoÅ›ci.

Kontenery IoC

Zostaje jeszcze pytanie, jak tworzyć obiekty jak np. Writer? NAJPROSTSZYM przykÅ‚adem Dependency Injection jest po prostu:

Worker worker = new Worker(new Writer());

To jest NAJPROSTSZY przykÅ‚ad, najbardziej banalny i caÅ‚kowicie bezużyteczny w prawdziwym Å›wiecie (chociaż czasem nie da siÄ™ inaczej). Co wiÄ™cej, powoduje dużo problemów. Załóżmy, że masz taki kod rozsiany po caÅ‚ej aplikacji i nagle konstruktor klasy Writer potrzebuje jeszcze jednego obiektu… Musisz to zmieniać w wielu miejscach. ZupeÅ‚na strata czasu.

Na szczęście powstało coś takiego jak kontenery DI.

Czym jest kontener DI

To specjalny kontener (pomyÅ›l o tym jak o klasie Dictionary<Type, object> na mocnych sterydach), który konfigurujesz podczas inicjalizowania aplikacji. Np. w metodzie Main. Możesz spotkać siÄ™ też z okreÅ›leniem „kontener IoC” – IoC to „Inversion of Control” – wzorzec projektowy, którego jednÄ… z implementacji jest wstrzykiwanie zależnoÅ›ci.

Konfigurując taki kontener, rejestrujesz w nim klasy, interfejsy, długości życia, a także sposoby w jakie konkretne obiekty mają zostać tworzone. Kontenery dają też możliwość rejestrowania własnych metod do tworzenia obiektów. Na końcu to właśnie kontener tworzy dla Ciebie w pełni działający obiekt.

W C# mamy do dyspozycji różne kontenery IoC. Najbardziej znane to chyba Autofac i Microsoft.Extensions.DependencyInjection. Autofac był wcześniej, natomiast w .NetCore przyszły mechanizmy z Microsoftu. Jako, że Autofac jest dużo starszy, PRAWDOPODOBNIE ma więcej możliwości, ale Microsoftowy odpowiednik jest wystarczający. Moim zdaniem jest też prostszy w użyciu i dlatego to nim się zajmiemy.

Długość życia serwisu

W związku z tym, że mechanizm DI musi widzieć kiedy tworzyć i zwalniać obiekty, podczas konfiguracji podajemy długość życia. Czyli mówimy kontenerowi jak długo obiekt powinien żyć, czy też kiedy go tworzyć. To może wyglądać strasznie, ale w rzeczywistości jest bardzo proste.

Niezależnie od tego, czy używasz Autofaca, Microsoft Dependency Injection, czy jeszcze innego mechanizmu, długości życia będą analogiczne:

Transient

Obiekt zarejestrowany jako transient będzie tworzony za każdym razem, gdy będzie potrzebny. To znaczy, że każda klasa, do której wstrzykujesz obiekt transient, będzie miała własną niepowtarzalną instancję, np:

class Worker
{
    IWriter writer;
    public Worker(IWriter writer)
    {
        this.writer = writer;
    }
}

class Manager
{
    IWriter writer;
    public Manager(IWriter writer)
    {
        this.writer = writer;
    }
}

JeÅ›li klasa Writer zostanie zarejestrowana jako transient, to instancje Writera w Worker i Manager zawsze bÄ™dÄ… różne. Po prostu klasa Writer zostanie utworzona na nowo przy każdym takim wstrzykniÄ™ciu.

Można by to przyrównać do tego kodu:

Writer w1 = new Writer();
Worker worker = new Worker(w1);

Writer w2 = new Writer();
Manager manager = new Manager(w2);

Scoped

W przypadku aplikacji desktopowych i mobilnych nie różni się to od singleton niczym (chyba że sam tworzysz scope). W przypadku aplikacji webowych, powstanie tylko jedna instancja takiego obiektu na żądanie http. Tzn.:

class Worker
{
    IWriter writer;
    public Worker(IWriter writer)
    {
        this.writer = writer;
    }
}

class Manager
{
    IWriter writer;
    public Manager(IWriter writer)
    {
        this.writer = writer;
    }
}

JeÅ›li teraz Worker zostanie zarejestrowany jako scoped i jesteÅ›my w obrÄ™bie jednego żądania HTTP, wtedy w Worker i Manager bÄ™dziemy mieli tÄ™ samÄ… instancjÄ™ klasy Writer. Po prostu obiekt Writer zostanie utworzony raz i wstrzykniÄ™ty do wszystkich innych obiektów w ramach jednego żądania. Obiekt umiera, gdy żądanie siÄ™ koÅ„czy i nie jest już dÅ‚użej używany.

Można by to zademonstrować takim kodem:

Response ManageRequest()
{
    Writer scopedWriter = new Writer();

    Worker worker = new Worker(scopedWriter);
    Manager manager = new Manager(scopedWriter);

    //tutaj praca na żądaniu..., a na koniec

    worker = null;
    manager = null;
    scopedWriter = null;
}

Singleton

Zostanie utworzona TYLKO JEDNA instancja takiej klasy w całej aplikacji. I ta jedna instancja będzie przekazywana innym obiektom przez cały okres działania aplikacji. Obiekt umiera wraz z aplikacją.

Można to porównać do takiego kodu:

if (mainWriter == null)
    mainWriter = new Writer();

Worker worker = new Worker(mainWriter);
Manager manager = new Manager(mainWriter);

DI od Microsoftu

Jeśli tworzysz aplikację webową, to masz już to w standardzie. Natomiast aplikacja konsolowa, WPF, czy WinForms wymaga, żebyś zainstalował paczkę NuGet: Microsoft.Extensions.DependencyInjection

Następnie musisz dodać do usings:

using Microsoft.Extensions.DependencyInjection;

Kontenery

Zwróć teraz uwagÄ™ na dwie klasy: ServiceCollection i ServiceProvider. W klasie ServiceCollection dodajemy wszystkie nasze serwisy – konfigurujemy kontener DI. Klasa ServiceProvider tworzy i zwraca nam konkretny obiekt, który potrzebujemy w danej chwili.

Weźmy teraz prostą aplikację konsolową:

class MainClass
{
    static void Main()
    {
        Console.Write("Podaj imiÄ™: ");
        string name = Console.ReadLine();

        Console.WriteLine($"Cześć {name}!");
        Console.ReadKey();
    }
}

Spróbujmy ją przerobić tak, żeby używała Dependency Injection. Standardowe podejście jest takie:

• w metodzie main konfigurujemy dependency injection
• pobieramy obiekt jakiejÅ› głównej klasy (np. w WPF/WinForms byÅ‚oby to najpewniej MainForm, czy też MainWindow)
• wywoÅ‚ujemy metodÄ™ z tej klasy

Ponieważ pracujemy na konsoli, musimy stworzyć głównÄ… klasÄ™ aplikacji. Klasa Main w tym wypadku sÅ‚uży tylko do konfiguracji:

class App
{
    public void Run()
    {

    }
}

W metodzie Main utworzymy instancjÄ™ klasy App, nastÄ™pnie wywoÅ‚amy metodÄ™ Run, która zrobi dokÅ‚adnie to samo, co Main po staremu. MoglibyÅ›my tutaj użyć klasy Console, ale żeby pobawić siÄ™ dependency injection, zrobimy to inaczej.

Używaj abstrakcji

Zamiast posÅ‚ugiwać siÄ™ bezpoÅ›rednio klasÄ… Console, utworzymy interfejs i zaimplementujemy go:

interface IUserInteraction
{
    void Print(string message);
    string Read();
}

class ConsoleInteraction : IUserInteraction
{
    public void Print(string message)
    {
        Console.Write(message);
    }

    public string Read()
    {
        return Console.ReadLine();
    }
}

Konfiguracja

Teraz w metodzie Main skonfigurujemy nasze DI. Aby to zrobić, najpierw trzeba utworzyć obiekt klasy ServiceCollection (pamiÄ™taj, że w aplikacjach webowych masz już to dostÄ™pne):

class MainClass
{
    static void Main()
    {
        var serviceCollection = new ServiceCollection();
        serviceCollection.AddTransient<IUserInteraction, ConsoleInteraction>();
        serviceCollection.AddSingleton<App>();

        using(var serviceProvider = serviceCollection.BuildServiceProvider())
        {
            var app = serviceProvider.GetService<App>();
            app.Run();
        }
    }
}

W linijce 5 tworzymy ServiceCollection, a nastÄ™pnie rejestrujemy dwa serwisy:

• ConsoleInteraction jako interfejs IUserInteraction – pamiÄ™taj, że w Microsoft DI najpierw podajesz interfejs, a później klasÄ™, która ten interfejs implementuje (jeÅ›li zrobisz na odwrót, aplikacja siÄ™ nie skompiluje). Teraz mechanizm DI wszÄ™dzie tam, gdzie zobaczy interfejs IUserInteraction, utworzy obiekt klasy ConsoleInteraction.
• KlasÄ™ App jako singleton. Jak widzisz – nie jest wymagany interfejs żeby zarejestrować klasÄ™. W przypadku klasy App interfejs nie ma wiÄ™kszego sensu, bo to główna klasa aplikacji. Ale czÄ™sto interfejs ma sens (głównie tam, gdzie jest zależnoÅ›ciÄ… dla innej klasy), wiÄ™c pamiÄ™taj o tym.

JeÅ›li nie wiesz czym jest singleton to po prostu obiekt który jest utworzony raz w caÅ‚ej aplikacji i żyje przez caÅ‚y cykl jej życia. Możesz siÄ™ też spotkać z okreÅ›leniem, że singleton jest antywzorcem, ale tu chodzi o innÄ… sytuacjÄ™ – rÄ™czne klasyczne tworzenie singletona. W naszym przypadku rejestrujemy klasÄ™ jako singleton w kontenerze DI i wszystko jest w porzÄ…dku.

Teraz tak. Dlaczego klasÄ™ ConsoleInteraction zarejestrowaliÅ›my jako transient? W przypadku tej aplikacji nie ma to żadnego znaczenia, bo i tak użyjemy jej tylko w jednym miejscu. ChciaÅ‚em po prostu pokazać, że tak to siÄ™ robi. Zazwyczaj klasy logujÄ…ce bÄ™dziesz rejestrowaÅ‚ jako singletony.

A dlaczego klasa App jest jako singleton? No przypomnij sobie czym jest singleton – jedna instancja klasy, która żyje przez caÅ‚y czas życia aplikacji. Czyli idealny zakres dla klasy, która reprezentuje caÅ‚Ä… aplikacjÄ™.

Pobieranie serwisów

W linijce 9 tworzymy ServiceProvider ze skonfigurowanego ServiceCollection. Od tego momentu ServiceProvider bÄ™dzie dostarczaÅ‚ nam obiekty, których potrzebujemy. Nie można już niczego zmienić w service collection (oczywiÅ›cie nikt Ci nie broni, żeby mieć kilka ServiceCollection i Providerów, ale jakoÅ› nie widzÄ™ w tym sensu).

Na koÅ„cu używamy ServiceProvider, żeby otrzymać obiekt klasy App. DosÅ‚ownie –

– Ej Ty! ServiceProvider, dej mnie no w peÅ‚ni dziaÅ‚ajÄ…cy obiekt klasy App!

To może nie jest niczym wyglÄ…dajÄ…cym super. Po prostu nie musiaÅ‚eÅ› tworzyć obiektu przez new, tylko za pomocÄ… ServiceProvidera. Ale pamiÄ™tasz IUserInteraction? Teraz dodajmy go do klasy App:

class App
{
    readonly IUserInteraction ui;
    public App(IUserInteraction ui)
    {
        this.ui = ui;
    }
    public void Run()
    {
        ui.Print("Podaj imiÄ™: ");
        string name = ui.Read();

        ui.Print($"Cześć {name}!");
        Console.ReadKey();
    }
}

W metodzie Main – już nic wiÄ™cej nie musisz robić. Otrzymasz znowu w peÅ‚ni dziaÅ‚ajÄ…cy obiekt klasy App! Klasa implementujÄ…ca IUserInteraction zostanie automagicznie utworzona i wstrzykniÄ™ta do App.

ServiceProvider i zwalnianie zasobów

Pewnie chodzi Ci po gÅ‚owie pytanie – co z klasami IDisposable? I czy sÄ… one zwalniane?

Zasadniczo tak. Spójrz, jak zostaÅ‚ utworzony ServiceProvider:

using (var serviceProvider = serviceCollection.BuildServiceProvider())
{
    var app = serviceProvider.GetRequiredService<App>();
    app.Run();
}

Teraz wszystkie obiekty zostanÄ… zwolnione po zwolnieniu ServiceProvidera. Natomiast ServiceProvider może też utworzyć tzw. zakres:

using (var serviceProvider = serviceCollection.BuildServiceProvider())
{
    using (var scope = serviceProvider.CreateScope())
    {
        var app = scope.ServiceProvider.GetRequiredService<App>();
        app.Run();
    }                
}

W aplikacji możemy mieć wiele takich zakresów. Np. w aplikacji webowej taki zakres jest tworzony na caÅ‚e żądanie HTTP. Obiekty zarejestrowanie jako scope i transient zostanÄ… usuniÄ™cie po wyjÅ›ciu z takiego zakresu, chyba że sÄ… zależnoÅ›ciami dla innych obiektów. JeÅ›li implementujÄ… interfejs IDisposable lub IAsyncDisposable, odpowiednie metody Dispose też zostanÄ… automatycznie wywoÅ‚ane. Singletony zostanÄ… zwolnione po zakoÅ„czeniu życia ServiceProvidera.

Ale uwaga! Jeśli zarejestrowałeś singleton, który jest zależny od innych klas i np. taką zależność zarejestrowałeś jako transient (lub scoped), to zwróć uwagę na to, że te zależności zostaną zwolnione dopiero po śmierci singletona. Przecież singleton na nich polega, dlatego też musi mieć dostęp do nich przez cały czas. W niektórych bibliotekach (np. boost::di dla C++) musisz rejestrować zależności dla singletona jako singleton. W .NET tak nie jest (przynajmniej nie w chwili pisania artykułu), ale miej świadomość długości życia.

Więcej na ten temat w kolejnym artykule, opisujących typowo Microsoft Dependency Injection

SkÄ…d ten ServiceProvider jest taki mÄ…dry?

W baaaardzo dużym skrócie można by opisać jego działanie tak:

1. Jaki chcesz typ? App? OK, sprawdźmy go
2. Typ App ma konstruktor z parametrami. Jaki jest pierwszy parametr? IUserInteraction
3. OK, muszÄ™ stworzyć teraz obiekt IUserInteraction. Co go implementuje? Z konfiguracji wynika, że ConsoleInteraction.
4. Jaki konstruktor ma ConsoleInteraction? DomyÅ›lny. No to tworzymy ConsoleInteraction
5. Skoro mam utworzone ConsoleInteraction, mogÄ™ teraz utworzyć App

ServiceProvider przeleci przez wszystkie zależnoÅ›ci (i zależnoÅ›ci tych zależnoÅ›ci) i utworzy je (jeÅ›li musi) w odpowiedniej kolejnoÅ›ci. Na koniec zwróci Ci w peÅ‚ni dziaÅ‚ajÄ…cy obiekt, o który prosiÅ‚eÅ›.

Możesz teraz uruchomić aplikację i zobaczyć jak działa. Przedebuguj ją sobie linijka po linijce i sprawdź kiedy wywołują się poszczególne konstruktory.

Wydajność aplikacji

Oczywiście taki mechanizm musi wpływać na wydajność aplikacji. Jednak w dzisiejszych czasach nie ma się tym co przejmować. Raczej nie powinno być to zauważalne. Używaj tego i będzie git 🙂 Pamiętaj, żeby nie optymalizować programu jeśli faktycznie nie musisz. Jeśli jest to problem, pomyśl czy klas, które są tworzone najdłużej nie zarejestrować jako singletony.

To na tyle, jeÅ›li chodzi o wstrzykiwanie zależnoÅ›ci. W innym artykule opiszÄ™ niedÅ‚ugo co jeszcze bardziej zaawansowanego można osiÄ…gnąć tym mechanizmem. WiÄ™c koniecznie zapisz siÄ