SoC in der mobilen Entwicklung: Was es ist, Prinzipien und Verantwortungstrennung

Was bedeutet die Abkürzung SoC

SoC steht für Separation of Concerns – „Verantwortungstrennung“ oder „Trennung von Interessensbereichen“. Im Entwicklungskontext bezeichnet der Begriff Concern jede trennbare Funktionalität: Darstellung der Benutzeroberfläche, Klickverarbeitung, Datenvalidierung, Netzwerkkommunikation oder Datenbankarbeit. Das SoC-Prinzip schreibt vor, Code um diese Bereiche herum zu gruppieren, sodass Änderungen in einem Bereich andere nicht beeinträchtigen.

Die Abkürzung SoC wird in technischer Literatur, Architekturdiskussionen und Framework-Dokumentation weit verbreitet verwendet. Beispielsweise wird in der Android Architecture Components-Dokumentation SoC wiederholt als Motivation für die Trennung von ViewModel und View genannt. In der iOS-Community wird der Begriff bei der Diskussion des Massive View Controller-Problems verwendet – eine direkte Folge fehlenden SoCs.

Es ist wichtig zu verstehen, dass SoC keine einmalige Aktion ist, sondern ein fortlaufender Prozess. Mit dem Wachstum einer Anwendung entstehen neue Verantwortungsbereiche und die Architektur muss überdacht werden. Eine gute Codebasis durchläuft mehrere Iterationen der Trennung, bevor sie einen stabilen Zustand erreicht, in dem jeder Concern isoliert und verwaltbar ist.

SoC vs Separation of Concerns

Separation of Concerns und seine Abkürzung SoC bezeichnen dasselbe Prinzip. Der Unterschied liegt nur im Nutzungskontext: Der vollständige Name wird in formellen Dokumenten, Lehrmaterialien und bei der erstmaligen Erklärung des Konzepts für neue Entwickler verwendet. SoC ist in technischen Diskussionen, Code-Reviews und Dokumentation praktisch, wo Kürze wichtig ist.

In einer professionellen Umgebung sind beide Begriffe austauschbar. Ein Entwickler kann sagen „hier wurde SoC verletzt“ oder „das verletzt Separation of Concerns“ – die Bedeutung ändert sich nicht. Allerdings wird in Stellenanzeigen und Architekturanforderungen häufiger der vollständige Name verwendet, während in Chats und Code-Reviews die Abkürzung genutzt wird. Die Kenntnis beider Varianten ist für einen komfortablen Einstieg in die Branche notwendig.

Es gibt terminologische Verwirrung: Die Abkürzung SoC wird auch im Hardware-Kontext für System-on-a-Chip (System auf einem Chip) verwendet. In der Mobilentwicklung ist der Kontext immer aus der Umgebung klar – wenn die Diskussion über Codearchitektur geht, ist Separation of Concerns gemeint. In diesem Artikel bezieht sich SoC immer auf das Prinzip der Verantwortungstrennung.

Wie SoC in der mobilen Architektur angewendet wird

Dreischichtenarchitektur ist die häufigste Methode zur Implementierung von SoC in mobilen Anwendungen. Sie teilt Code in Presentation (UI), Domain (Geschäftslogik) und Data (Datenquellen). Jede Schicht enthält streng definierte Klassentypen und ist über Schnittstellen von Nachbarn isoliert. Dieser Ansatz ist gleichermaßen effektiv für iOS-, Android- und Flutter-Projekte.

Presentation-Schicht und ViewModel

View und ViewModel bilden die Präsentationsschicht. Die View ist für die Darstellung der Oberfläche und die Weiterleitung von Benutzerereignissen verantwortlich. Das ViewModel hält den Bildschirmzustand und wandelt Daten aus der Domain-Schicht in ein anzeigebereites Format um. Das ViewModel hat keine Referenzen auf Activity, Fragment oder UIViewController – das gewährleistet SoC zwischen UI und Logik.

Zum Beispiel in Android Jetpack überlebt das ViewModel eine Bildschirmdrehung, während die UI neu erstellt wird. Ohne SoC müsste der Zustand in der Activity gespeichert werden, was Lebenszyklusverwaltung mit Daten vermischen würde. Das ViewModel löst dieses Problem isoliert und demonstriert eine saubere Umsetzung des Prinzips der Verantwortungstrennung.

Domain-Schicht und Use Cases

Use Cases enthalten plattformunabhängige Geschäftsregeln. Diese Schicht importiert weder Android SDK, iOS UIKit noch Flutter Framework. Ein Use Case erhält Daten vom Repository, wendet Geschäftslogik an und gibt das Ergebnis zurück. Dank SoC kann ein einziger Use Case auf verschiedenen Bildschirmen und Plattformen wiederverwendet werden.

Ein klassisches Beispiel ist der ValidateAndSaveUseCase für ein Registrierungsformular. Er validiert E-Mail und Passwort, ruft das UserRepository zum Speichern auf und gibt ein ValidationResult zurück. Weder die UI noch die Datenbank kennen die Validierungsregeln – sie sind an einem Ort konzentriert, was ihre Änderung vereinfacht.

Data-Schicht und Repository

Repository abstrahiert Datenquellen vom Rest der Anwendung. Das ViewModel weiß nicht, woher die Daten stammen – von REST API, GraphQL, lokaler Datenbank oder Cache. Das Repository entscheidet, welche Quelle verwendet wird, und verbirgt diese Logik hinter einer Schnittstelle. Das ist SoC zwischen Datenabruf und Datennutzung.

DataSource bietet eine noch tiefere Trennung: RemoteDataSource ist nur für HTTP-Anfragen zuständig, LocalDataSource für die Arbeit mit Room, CoreData oder SharedPreferences. Das Repository kombiniert sie mithilfe von Caching-Strategien. Jede DataSource kann unabhängig ersetzt werden, was bei der Migration zwischen Servern oder Datenbanken kritisch ist.

Ein solches mehrstufiges DataSource-System implementiert SoC auf Infrastrukturebene: Netzwerkkommunikation, lokale Speicherung und Caching sind separate Concerns, jeder mit eigener Logik und Lebenszyklus. Beim Austausch eines HTTP-Clients ändert sich nur RemoteDataSource, während Repository und höhere Schichten unberührt bleiben, was den praktischen Wert der Verantwortungstrennung bestätigt.

SoC in Architekturmustern

MVP (Model-View-Presenter) war eines der ersten Muster, das SoC in der mobilen Entwicklung explizit implementierte. Der Presenter enthält die Logik und steuert die View über eine Schnittstelle. Die View ist passiv – sie zeigt nur an, was der Presenter sagt. Die Trennung vereinfacht Tests: Der Presenter wird ohne Emulator getestet und die View bleibt so einfach, dass nichts kaputtgehen kann.

MVVM fügte reaktive Bindung hinzu: Die View abonniert Änderungen des ViewModel über Observable oder StateFlow. Das ViewModel speichert keine Referenz auf die View, was das Risiko von Speicherlecks beseitigt und Concerns noch stärker trennt. In Android wurde MVVM dank Jetpack ViewModel und LiveData zum Standard, in iOS dank Combine und RxSwift.

Clean Architecture von Robert Martin treibt SoC zu einer radikalen Trennung in Ringe. Der äußere Ring (Frameworks und Treiber) hängt vom inneren (Entitäten) ab, aber nicht umgekehrt. In der Praxis implementieren mobile Projekte selten alle vier Ringe – Domain- und Data-Schichten um Presentation reichen aus. Aber das Prinzip der „Abhängigkeit nach innen“ bietet bedeutende Vorteile beim Wechsel von Frameworks.

// View — nur Anzeige, keine Logik
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — enthält Bildschirmlogik, kennt UIKit nicht
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — Geschäftslogik, plattformunabhängig
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Das Beispiel zeigt drei Ebenen von SoC: LoginViewController leitet nur Ereignisse weiter, LoginViewModel verwaltet den Zustand, LoginUseCase enthält Geschäftsregeln. Jede Klasse wird unabhängig getestet, und der Wechsel des UI-Frameworks beeinträchtigt den Use Case nicht.

Typische SoC-Verletzungen in mobilen Projekten

Massive View Controller ist die häufigste SoC-Verletzung in iOS. Eine Klasse, die die UI verwaltet, Netzwerkanfragen bearbeitet, JSON parst und Daten speichert, verletzt das Prinzip auf allen Ebenen. Die Lösung besteht darin, jede Verantwortung in eine separate Komponente zu extrahieren: NetworkingService, JSONParser, CoreDataStack, und dem ViewController nur die View-Verwaltung zu überlassen.

In Android ist ein ähnliches Problem die God Activity oder God Fragment. Eine Aktivität, die Daten lädt, Formulare validiert, Dialoge anzeigt und die UI aktualisiert. Behoben wird dies durch die Einführung von ViewModel und Repository, die die Zustandsverwaltung und Datenverarbeitung übernehmen. Das ViewModel schützt auch vor Datenverlust bei Bildschirmdrehung.

Die dritte Verletzung ist die Vermischung von Plattform- und Geschäftscode. Zum Beispiel das Platzieren einer HTTP-Anfrage direkt in einer SwiftUI View oder Android Composable. Dies macht den Code nicht portierbar und schwer testbar. Der richtige Ansatz ist, die Anfrage in ein Repository zu verschieben, das über einen Use Case aufgerufen wird, während die View nur das Ergebnis abonniert. Jedes Element des Systems löst seine eigene Aufgabe und überschreitet seine Grenzen nicht.