Model-View-Controller (MVC)
Architekturmuster zur Trennung von Datenmodell, Darstellung und Steuerung, um Wartbarkeit und Testbarkeit von UI-nahen Systemen zu verbessern.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Unklare Abgrenzung führt zu vermischter Logik
- Controller als Dumping-Ground für Geschäftslogik
- Fehlende Disziplin beim Schichten-Design erhöht Wartungskosten
- Halte Controller dünn; Geschäftliche Logik im Model
- Definiere explizite Contracts für View-Daten
- Nutze Automatisierte Tests zur Absicherung der Trennung
I/O & Ressourcen
- Domänenmodell und Geschäftsregeln
- UI-Designs oder Templates
- Event- und Routing-Spezifikationen
- Getrennte Schichten (Model/View/Controller)
- Verbesserte Testabdeckung und modularisierte Komponenten
- Dokumentierte Schnittstellen und Contracts
Beschreibung
Das Model-View-Controller (MVC)-Muster trennt Anwendungen in Model, View und Controller, um Daten, Darstellung und Benutzereingaben zu entkoppeln. Es steigert Wartbarkeit, Testbarkeit und parallele Entwicklung in Web- und Desktopanwendungen durch klare Verantwortlichkeiten. Gleichzeitig erhöht MVC die Architekturkomplexität, erfordert Disziplin und kann zu Controller-Bloat führen.
✔Vorteile
- Verbesserte Wartbarkeit durch klar definierte Schichten
- Bessere Testbarkeit der Geschäftslogik getrennt von der UI
- Erleichtert parallele Entwicklung von UI und Backend
✖Limitationen
- Erhöhter Architektur- und Koordinationsaufwand
- Nicht optimal für sehr dynamische komponentenbasierte UIs
- Kann zu übergroßen Controllern (Controller-Bloat) führen
Trade-offs
Metriken
- Anteil unit-getesteter Geschäftslogik
Misst den Prozentsatz der Domänenlogik, der durch Unit-Tests abgedeckt ist.
- Durchschnittliche Controller-Größe
Metrik zur Erkennung von Controller-Bloat anhand LOC oder Anzahl von Methoden.
- Time-to-Change für UI-Anpassungen
Zeit vom Änderungswunsch bis zur produktiven Bereitstellung einer UI-Änderung.
Beispiele & Implementierungen
Ruby on Rails
Rails implementiert MVC als zentrales Architekturprinzip mit klaren Konventionen für Models, Views und Controller.
ASP.NET MVC
Microsofts Framework bietet eine strukturierte MVC-Implementierung für Webanwendungen mit Routing und Controller-Lifecycle.
Desktop-Anwendungen (z. B. Java Swing Varianten)
MVC-Konzepte finden sich in vielen Desktop-UI-Frameworks, um Darstellung und Logik zu trennen.
Implementierungsschritte
Analysiere bestehende Codepfade und identifiziere Verantwortlichkeiten
Extrahiere das Domänenmodell aus UI-Logik
Implementiere Views getrennt von Controller-Logik
Ergänze Tests für Model- und Controller-Schichten
⚠️ Technische Schulden & Engpässe
Tech Debt
- Historisch gewachsene Controller mit gemischter Logik
- Ungetestete Model-Funktionen im Code-Stamm
- Fehlende Schnittstellendefinitionen zwischen Views und Controllern
Bekannte Engpässe
Beispiele für Missbrauch
- Verlagerung komplexer Validierungen in Controller statt Model
- Verwendung von MVC als Boilerplate ohne echte Schichttrennung
- Übermäßige Nutzung von globalen Zuständen zwischen Schichten
Typische Fallen
- Unzureichende Tests für Controller-Interaktionen
- Fehlende Dokumentation der Contracts zwischen Schichten
- Inkonsistente Benennung und Verantwortungszuweisung
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Erfordert klare Schnittstellendefinitionen
- • Nicht ideal für rein komponentenbasierte Frameworks ohne zentrale Controller
- • Einarbeitungszeit für Entwickler zur korrekten Schichttrennung