Dependency Injection

Das Problem: Überall .shared

Schau dir an, wie Code oft entsteht:

struct RecipeListView: View {
    @State private var recipes: [Meal] = []

    var body: some View {
        List(recipes) { ... }
            .task {
                recipes = (try? await MealAPI.shared.meals(in: "Dessert")) ?? []
            }
    }
}

struct FavoriteButton: View {
    let meal: Meal
    var body: some View {
        Button("Favorit") {
            FavoritesStore.shared.toggle(id: meal.id)
            Analytics.shared.track("favorite")
        }
    }
}

Jede View holt sich, was sie braucht, über ein globales .shared-Objekt, ein sogenanntes Singleton. Das ist bequem. Aber:

• Previews laden echte Daten aus dem Netz, sind langsam und funktionieren offline gar nicht.
• Tests (Lektion 4.11) können die Dienste nicht ersetzen.
• Du kannst nicht sehen, wovon eine View abhängt, ohne jede Zeile zu lesen.
• Willst du die API austauschen, etwa gegen eine Version mit Cache, musst du jede Stelle ändern.

Die Lösung heißt Dependency Injection, auf Deutsch etwa „Abhängigkeiten von außen hineingeben“. Der Name klingt kompliziert, die Idee ist einfach: Ein Baustein holt sich seine Abhängigkeiten nicht selbst, er bekommt sie.

Weg 1: Über den Initializer

Den einfachsten Weg kennst du schon aus Lektion 4.11: Die Abhängigkeit kommt als Parameter, mit einem sinnvollen Standardwert.

@Observable
class MealListModel {
    private let service: any MealService

    init(service: any MealService = MealAPI()) {
        self.service = service
    }
}

Das ist ideal für Modelle und Logik: Jede Abhängigkeit ist im Initializer sichtbar, und Tests übergeben einfach einen Ersatz.

Für Views wird es aber mühsam. Braucht eine View tief unten im Baum den Dienst, müsste jede View auf dem Weg dorthin ihn als Parameter durchreichen, auch wenn sie ihn selbst gar nicht braucht. Das ist dasselbe Problem wie beim Durchreichen von Daten, das du aus Lektion 3.3 kennst.

Weg 2: Über die Environment

Für Views ist die Environment der natürliche Weg (Lektion 3.3). Du kennst sie für @Observable-Objekte. Für Dienste, die über ein Protokoll beschrieben sind, eignet sich ein eigener Environment-Schlüssel mit @Entry:

extension EnvironmentValues {
    @Entry var mealService: any MealService = MealAPI()
}

• @Entry erzeugt den Schlüssel mit einem Standardwert, hier die echte API.
• Jede View kann ihn lesen, egal wie tief sie im Baum steckt.

struct RecipeListView: View {
    @Environment(\.mealService) private var service
    @State private var recipes: [Meal] = []

    var body: some View {
        List(recipes) { ... }
            .task {
                recipes = (try? await service.meals(in: "Dessert")) ?? []
            }
    }
}

Und an jeder Stelle im Baum kannst du ihn ersetzen:

#Preview("Mit Beispieldaten") {
    RecipeListView()
        .environment(\.mealService, PreviewMealService())
}

#Preview("Fehler") {
    RecipeListView()
        .environment(\.mealService, FailingMealService())
}

Die Ersatzdienste sind kleine Structs:

struct PreviewMealService: MealService {
    func meals(in category: String) async throws -> [Meal] {
        [
            Meal(id: "1", name: "Pfannkuchen", thumbnail: nil),
            Meal(id: "2", name: "Apfelstrudel", thumbnail: nil),
            Meal(id: "3", name: "Kaiserschmarrn", thumbnail: nil)
        ]
    }
}

struct FailingMealService: MealService {
    func meals(in category: String) async throws -> [Meal] {
        throw URLError(.notConnectedToInternet)
    }
}

Environment und ViewModels

Was, wenn ein ViewModel den Dienst braucht? Ein ViewModel ist keine View und kann @Environment nicht lesen. Die View liest den Dienst und gibt ihn weiter:

struct RecipeScreen: View {
    @Environment(\.mealService) private var service
    @State private var model: MealListModel?

    var body: some View {
        Group {
            if let model {
                MealListContent(model: model)
            } else {
                ProgressView()
            }
        }
        .task {
            if model == nil {
                model = MealListModel(service: service)
            }
        }
    }
}

Das Modell wird erst in .task erzeugt, wenn die Environment verfügbar ist, und nur einmal. Im Initializer der View geht das nicht, weil @Environment dort noch keinen Wert hat.

Weg 3: Eine zentrale Stelle für alle Dienste

Hat eine App mehrere Dienste, also API, Favoriten, Analyse, Benachrichtigungen, lohnt es sich, sie an einer Stelle zusammenzustellen. Diese Stelle heißt oft Composition Root, die Wurzel, an der alles zusammengesteckt wird.

struct AppDependencies {
    var mealService: any MealService
    var favorites: FavoritesStore
    var analytics: any AnalyticsService

    static func live() -> AppDependencies {
        AppDependencies(
            mealService: MealAPI(),
            favorites: FavoritesStore(defaults: .standard),
            analytics: ConsoleAnalytics()
        )
    }

    static func preview() -> AppDependencies {
        AppDependencies(
            mealService: PreviewMealService(),
            favorites: FavoritesStore(defaults: UserDefaults(suiteName: "preview")!),
            analytics: NoAnalytics()
        )
    }
}

Für analytics gibt es wie für mealService einen eigenen @Entry-Schlüssel. Ein kleiner Modifier hängt dann alle Dienste auf einmal an:

extension View {
    func dependencies(_ deps: AppDependencies) -> some View {
        self
            .environment(\.mealService, deps.mealService)
            .environment(\.analytics, deps.analytics)
            .environment(deps.favorites)
    }
}

In der App:

@main
struct RecipesApp: App {
    @State private var deps = AppDependencies.live()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .dependencies(deps)
        }
    }
}

Und in jeder Preview:

#Preview {
    RecipeDetail(meal: .sample)
        .dependencies(.preview())
}

Der große Vorteil: Auf einen Blick siehst du alle Dienste der App, und für jede Umgebung, ob echte App, Previews, UI-Tests (Lektion 4.12) oder später eine Demo-Version, gibt es genau eine Stelle, an der festgelegt wird, was verwendet wird.

Und Singletons?

Sind Singletons also verboten? Nein. Apple selbst verwendet sie: URLSession.shared, UserDefaults.standard, FileManager.default. Sie sind in Ordnung, wenn:

• es den Dienst wirklich nur einmal geben kann und
• du ihn in Tests und Previews nicht ersetzen musst.

Das Problem ist nicht das Singleton selbst, sondern wenn Code es sich überall direkt holt. Ein guter Kompromiss: Das Singleton darf es geben, aber nur an der zentralen Stelle wird es verwendet, als Standardwert, und alle anderen bekommen es übergeben.

init(session: URLSession = .shared) { ... }   // ✅ austauschbar, bequem

Welches Muster wann?

Typische Fehler

Preview lädt echte Daten oder stürzt ab

Die View holt sich einen Dienst über .shared oder erzeugt ihn selbst. Lies ihn aus der Environment und ersetze ihn in der Preview.

@Environment im Initializer ist leer

Environment-Werte stehen erst in body, .task oder .onAppear zur Verfügung, nicht im init der View. Erzeuge abhängige Modelle in .task oder eine Ebene höher.

Abhängigkeiten werden überall einzeln durchgereicht

Lange Parameterketten durch mehrere Views, die den Dienst gar nicht selbst brauchen. Für Views ist die Environment der bessere Weg.

Fehlendes Objekt in der Environment

No Observable object of type FavoritesStore found.

Ein @Environment(FavoritesStore.self) wird gelesen, aber nirgends darüber mit .environment(...) gesetzt. Passiert oft in Previews. Mit einem dependencies(.preview())-Modifier ist das ein für alle Mal gelöst.

FAQ

Übungen

struct SlowMealService: MealService {
    var delay: Duration = .seconds(2)
    var meals: [Meal] = [Meal(id: "1", name: "Pfannkuchen", thumbnail: nil)]

    func meals(in category: String) async throws -> [Meal] {
        try await Task.sleep(for: delay)
        return meals
    }
}

#Preview("Langsam") {
    NavigationStack {
        RecipeListView()
    }
    .environment(\.mealService, SlowMealService())
}

Zusammenfassung

• Dependency Injection: Ein Baustein bekommt seine Abhängigkeiten, statt sie sich selbst zu holen.
• Initializer mit Standardwert für Modelle und Logik: sichtbar, einfach, testbar.
• Environment mit @Entry für Dienste, die Views brauchen, ersetzbar in Previews und Teilbäumen.
• @Environment hat im init noch keinen Wert: abhängige Modelle in .task oder eine Ebene höher erzeugen.
• Eine zentrale Stelle wie AppDependencies stellt alle Dienste für App, Previews und Tests zusammen.
• Singletons sind in Ordnung als Standardwert, aber nicht als direkter Zugriff überall im Code.

Spickzettel

// Initializer
init(service: any MealService = MealAPI()) { self.service = service }

// Environment
extension EnvironmentValues {
    @Entry var mealService: any MealService = MealAPI()
}
@Environment(\.mealService) private var service
.environment(\.mealService, PreviewMealService())

// Zentrale Stelle
struct AppDependencies {
    var mealService: any MealService
    static func live() -> Self { .init(mealService: MealAPI()) }
    static func preview() -> Self { .init(mealService: PreviewMealService()) }
}
extension View {
    func dependencies(_ d: AppDependencies) -> some View {
        environment(\.mealService, d.mealService)
    }
}

#Preview { MyView().dependencies(.preview()) }