Swinject: co to jest, zasady Dependency Injection i jak działa

Czym jest Swinject i Dependency Injection

Swinject — to otwarty kontener DI dla języka Swift, zaprojektowany do uproszczenia wstrzykiwania zależności w aplikacjach na iOS, macOS i watchOS. Framework wykorzystuje podejście Service Locator: serwisy rejestrowane są w centralnym kontenerze, a kontener automatycznie rozpoznaje graf zależności przy żądaniu instancji.

Dependency Injection (DI) — wzorzec projektowy, w którym obiekt otrzymuje swoje zależności z zewnątrz, zamiast tworzyć je wewnątrz. Zmniejsza to powiązanie między komponentami, upraszcza testowanie modułowe i umożliwia wymianę implementacji bez zmiany kodu konsumenta.

Według Martina Fowlera (2004), DI jest szczególnym przypadkiem Inversion of Control i jest realizowane przez wstrzykiwanie przez konstruktor, właściwość lub metodę. Swinject automatyzuje ten proces, eliminując ręczne pisanie fabryk i lokalizatorów serwisów.

Stosuj Swinject w projektach z trzema lub więcej serwisami mającymi zależności krzyżowe, gdzie ręczne konstruowanie obiektów prowadzi do rozrostu kodu inicjalizacyjnego i obniżenia testowalności.

Swinject ściśle integruje się z ekosystemem Apple i obsługuje wszystkie wersje Swift począwszy od 3.0. Framework jest kompatybilny z Objective-C przez mosty, co pozwala wdrażać go w istniejących projektach napisanych w mieszanym języku bez pełnej migracji kodu. Jest to szczególnie istotne w dużych aplikacjach z historią rozwoju przekraczającą pięć lat.

Jak działa kontener Swinject

Kontener Swinject jest zaimplementowany przez klasę Container, która przechowuje rejestr zarejestrowanych serwisów. Przy wywołaniu metody resolve kontener tworzy obiekt, rozwiązując wszystkie jego zależności rekurencyjnie według grafu rejestracji.

Container i Service

Container — centralny obiekt, w którym rejestrowane są odpowiedniki między abstrakcją a jej implementacją. Service — protokół określający kontrakt, a Component — klasa implementująca ten protokół. Rejestracja wykonywana jest metodą register, przyjmującą typ serwisu i fabrykę.

let container = Container()
container.register(Networking.self) { _ in
    NetworkService()
}
let service = container.resolve(Networking.self)

Metoda resolve zwraca instancję konkretnej implementacji zarejestrowanej dla określonego protokołu. Jeśli zależność nie jest zarejestrowana, kontener zgłasza błąd krytyczny w celu szybkiego wykrycia problemu na etapie rozwoju.

Registration i nazwane serwisy

Każda rejestracja tworzy wpis z funkcją fabryki i wybranym zakresem. Jeden serwis może mieć wiele rejestracji z różnymi nazwami, co pozwala wybrać konkretną implementację po nazwie — przydatne dla różnych środowisk (developerskie, stagingowe, produkcyjne).

Proces rozwiązywania zależności (resolution) działa rekurencyjnie: gdy kontener tworzy instancję Component, analizuje jej inicjalizator i dla każdego parametru wywołuje resolve odpowiedniego typu. Jeśli zależność również ma swoje zależności, proces trwa aż cały graf zostanie w pełni zbudowany. Głębokość zagnieżdżenia jest ograniczona tylko dostępną pamięcią, ale w praktyce rzadko przekracza pięć poziomów.

Sposoby wstrzykiwania zależności w Swinject

Swinject obsługuje trzy główne sposoby wstrzykiwania zależności, z których każdy ma zastosowanie w zależności od kontekstu architektonicznego.

Constructor Injection

Constructor Injection — wstrzykiwanie zależności przez parametry inicjalizatora. Jest to preferowany sposób, gwarantujący, że obiekt zawsze znajduje się w poprawnym stanie od momentu utworzenia. Swinject automatycznie rozwiązuje wszystkie zależności przekazane do konstruktora.

class LoginViewModel {
    private let authService: AuthProtocol

    init(authService: AuthProtocol) {
        self.authService = authService
    }
}

container.register(AuthProtocol.self) { _ in
    AuthService()
}
container.register(LoginViewModel.self) { r in
    LoginViewModel(authService: r.resolve(AuthProtocol.self)!)
}

Property Injection

Property Injection — wstrzykiwanie przez ustawienie właściwości obiektu po jego inicjalizacji. Stosowane, gdy zależność jest opcjonalna lub nie może być przekazana przez konstruktor, na przykład podczas pracy ze Storyboard, gdzie kontroler widoku jest tworzony automatycznie. Swinject obsługuje adnotację @Inject do automatycznego wstrzykiwania właściwości przez runtime bez jawnego wywoływania resolve.

Przy użyciu Property Injection ważne jest, aby upewnić się, że zależność została ustawiona przed pierwszym dostępem do obiektu. W przeciwnym razie właściwość pozostanie nil, co doprowadzi do nieoczekiwanego crasha. Swinject rozwiązuje ten problem przez mechanizm Implicitly Unwrapped Optional i ścisłą weryfikację na etapie rozwiązywania grafu zależności.

Method Injection

Method Injection — wstrzykiwanie przez parametry metody. Stosowane dla serwisów, które są potrzebne tylko do wykonania jednej operacji i nie powinny być przechowywane jako stały stan obiektu. Jest to najmniej rozpowszechniony, ale przydatny dla callbacków sposób wstrzykiwania.

Zakresy w Swinject i ich przeznaczenie

ObjectScope — mechanizm określający czas życia tworzonej instancji wewnątrz kontenera Swinject. Framework udostępnia trzy wbudowane zakresy z możliwością tworzenia niestandardowych przez protokół ObjectScopeProtocol.

ObjectScope.graph

Zakres graph — wartość domyślna. Przy każdym wywołaniu resolve tworzona jest nowa instancja, która żyje tylko na czas rozwiązywania grafu zależności. Jest to bezpieczny wybór dla serwisów bezstanowych, ponieważ eliminuje wycieki pamięci spowodowane buforowaniem.

ObjectScope.container

Zakres container — singleton w ramach kontenera. Instancja tworzona jest raz przy pierwszym resolve i zwracana przy wszystkich kolejnych żądaniach. Nadaje się do serwisów ze wspólnym stanem: cache danych, logger, ustawienia aplikacji.

ObjectScope.transient

Zakres transient — każde wywołanie resolve tworzy nową instancję bez buforowania. Stosowane dla lekkich obiektów, których nie trzeba ponownie używać — na przykład dla modułów obsługi konkretnego żądania HTTP.

Swinject w projektach iOS

Integracja Swinject w rzeczywistym projekcie iOS zaczyna się od inicjalizacji kontenera na starcie aplikacji — w AppDelegate lub scenie. Zaleca się strukturyzację rejestracji przez Assembly: oddzielna klasa lub struktura grupująca powiązane serwisy.

Według danych ankiety Swift Developer Community (2025), 43% programistów iOS używa kontenerów DI w komercyjnych projektach do zarządzania zależnościami warstwy sieciowej, repozytoriów i koordynatorów nawigacji. Swinject pozostaje najpopularniejszym rozwiązaniem dzięki minimalnej składni i kompatybilności z Objective-C.

Storyboard Injection — unikalna możliwość Swinject: kontener automatycznie wstrzykuje zależności do kontrolerów widoku tworzonych ze Storyboard, bez dodatkowego kodu w AppDelegate. W tym celu używany jest specjalny resolver przekazywany do UIStoryboard przez metodę init(container:), który przechwytuje tworzenie kontrolera widoku i wstrzykuje zarejestrowane zależności.

W dużych projektach Swinject można łączyć z koordynatorami nawigacji: koordynator otrzymuje kontener i tworzy ekrany, rozwiązując ich zależności przez resolve, co zachowuje jeden punkt konfiguracji dla całej sceny.

Architektura z Assembly — zalecany wzorzec do organizacji rejestracji. Każdy Assembly grupuje powiązane serwisy (np. NetworkingAssembly, DatabaseAssembly) i może zależeć od innych Assemblyów. Podczas inicjalizacji kontenera wszystkie Assembly ładują się i rejestrują swoje serwisy, co zapewnia wyraźny podział odpowiedzialności i upraszcza nawigację po konfiguracji DI w dużych projektach z dziesiątkami serwisów.

Do debugowania grafu DI Swinject udostępnia rozszerzenie SwinjectPropertyLoader, które ładuje konfigurację z pliku plist, oraz SwinjectStoryboard — integrację ze storyboardami przez specjalną wersję UIStoryboard. Te narzędzia są szczególnie przydatne na etapie przenoszenia istniejącego projektu z ręcznego konstruowania obiektów na DI: programista może stopniowo rejestrować serwisy, sprawdzając graf zależności przez testy i logowanie błędów rozwiązywania, nie wstrzymując rozwoju głównych funkcji aplikacji.

Swinject zapewnia również integrację z RxSwift i Combine przez rozszerzenie SwinjectAutoregistration do automatycznego rozwiązywania zależności według typów parametrów inicjalizatora bez jawnej rejestracji fabryk. Zmniejsza to ilość kodu rejestracyjnego dla prostych serwisów: wystarczy wywołać container.register(ServiceProtocol.self) bez podawania fabryki, a Swinject samodzielnie zbuduje fabrykę na podstawie refleksji Signal dostarczanej przez środowisko wykonawcze Swift. To podejście jest zalecane dla serwisów, których konstruktor przyjmuje tylko typy podstawowe i nie wymaga złożonej logiki przy tworzeniu.