06 Quiz: Architekturmuster
January 2026 (1540 Words, 9 Minutes)
Neu: Interaktives Quiz verfügbar!
Möchtest du deinen Fortschritt verfolgen und sofortiges Feedback erhalten? Probiere unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.
Anleitung
- Dieses Quiz testet dein Verständnis der wichtigsten Konzepte aus Vorlesung 10 Teil 2: Architekturmuster
- Jede Frage hat 4 Optionen mit genau einer richtigen Antwort
- Versuche zu antworten, ohne in den Vorlesungsmaterialien nachzuschlagen
- Konzentriere dich auf das Verständnis der Konzepte, nicht auf das Auswendiglernen von Details
Frage 1: MVC Model-Verantwortung
Was ist im Model-View-Controller (MVC) Muster die Hauptverantwortung des Models?
A) Daten für Benutzer anzeigen und visuelle Präsentation handhaben
B) Daten, Geschäftslogik und Anwendungszustand verwalten
C) Benutzereingaben verarbeiten und zwischen Komponenten koordinieren
D) HTML-Templates rendern und CSS-Styles verwalten
Antwort anzeigen
Richtige Antwort: B
Das Model in MVC ist verantwortlich für Daten und Geschäftslogik. Es verwaltet die Anwendungsdaten, setzt Geschäftsregeln durch und ist vollständig unabhängig von der Benutzeroberfläche. Die View handhabt die Anzeige (A), der Controller handhabt die Koordination von Benutzereingaben (C), und das Rendern von Templates ist eine View-Verantwortung (D).
Frage 2: MVC Controller-Rolle
Was ist die Rolle des Controllers in der MVC-Architektur?
A) Daten aus der Datenbank speichern und abrufen
B) Das visuelle Layout und Styling der Anwendung definieren
C) Benutzereingaben verarbeiten und Updates zwischen Model und View koordinieren
D) Netzwerkverbindungen und API-Endpunkte verwalten
Antwort anzeigen
Richtige Antwort: C
Der Controller fungiert als Koordinator in MVC. Er empfängt Benutzereingaben von der View, verarbeitet sie (und aktualisiert möglicherweise das Model) und löst View-Updates aus, wenn sich das Model ändert. Datenspeicherung ist infrastrukturbezogen, visuelles Layout ist Aufgabe der View, und Netzwerkmanagement ist typischerweise getrennt von der MVC-Triade.
Frage 3: MVC-Vorteile
Was ist ein primärer Vorteil der Trennung von Zuständigkeiten mit MVC?
A) Es macht die Anwendung schneller durch Reduzierung der Codegröße
B) Es ermöglicht UI-Designern und Backend-Entwicklern unabhängig zu arbeiten
C) Es eliminiert die Notwendigkeit für Tests
D) Es generiert automatisch Dokumentation
Antwort anzeigen
Richtige Antwort: B
Der Hauptvorteil der MVC-Trennung ist die Ermöglichung paralleler Entwicklung. UI-Designer können an Views arbeiten, ohne die Geschäftslogik zu verstehen, während Entwickler an Models arbeiten können, ohne die Oberfläche anzufassen. Diese Trennung ermöglicht auch das Testen von Models unabhängig von der UI und die Verwendung desselben Models mit mehreren Views (Web, Mobile, CLI).
Frage 4: Django MTV-Zuordnung
In Djangos MTV-Terminologie (Model-Template-View), was entspricht dem Controller im traditionellen MVC?
A) Das Model
B) Das Template
C) Die View
D) Die URLconf
Antwort anzeigen
Richtige Antwort: C
Django verwendet andere Terminologie, aber dasselbe Muster. In Django: Das Model ist weiterhin das Model, das Template entspricht der MVC-View (Präsentation), und Djangos View entspricht dem MVC-Controller (Verarbeitung von Anfragen und Koordination). Dieser Namensunterschied verwirrt oft Entwickler, aber die zugrundeliegende Trennung der Zuständigkeiten ist identisch.
Frage 5: Schichtenarchitektur-Abhängigkeiten
Wie sollten in einer richtig strukturierten Schichtenarchitektur die Abhängigkeiten fließen?
A) Nur aufwärts (Daten → Business → Präsentation)
B) Nur abwärts (Präsentation → Business → Daten)
C) In jede Richtung nach Bedarf für Effizienz
D) Nur horizontal innerhalb derselben Schicht
Antwort anzeigen
Richtige Antwort: B
Abhängigkeiten in der Schichtenarchitektur müssen nur abwärts fließen. Die Präsentationsschicht kann von Business abhängen, Business kann von Daten abhängen, aber niemals umgekehrt. Dies stellt sicher, dass niedrigere Schichten unabhängig und wiederverwendbar bleiben. Die Datenschicht sollte niemals über die UI Bescheid wissen, und die Business-Schicht sollte nicht davon abhängen, wie Daten präsentiert werden.
Frage 6: Schichtverletzung
Welches der folgenden stellt eine Verletzung der Schichtenarchitektur-Prinzipien dar?
A) Ein Controller, der eine Service-Methode aufruft
B) Ein Repository, das ein Datenbank-ORM verwendet
C) Eine UI-Komponente, die direkt die Datenbank abfragt
D) Ein Service, der Geschäftsregeln validiert
Antwort anzeigen
Richtige Antwort: C
Eine UI-Komponente (Präsentationsschicht), die direkt die Datenbank (Datenschicht) abfragt, verletzt die Regel “keine Schichten überspringen”. Die Präsentationsschicht sollte durch die Business-Schicht gehen, die dann auf die Datenschicht zugreift. Die anderen Optionen sind korrekt: Controller, die Services aufrufen (Präsentation → Business), Repositories, die ORMs verwenden (innerhalb der Datenschicht), und Services, die Regeln validieren (Business-Schicht-Verantwortung), sind alle richtige Schicht-Interaktionen.
Frage 7: Schichtvorteile
Warum ist Schichtenarchitektur vorteilhaft, wenn du von SQLite auf PostgreSQL wechseln musst?
A) Du musst die gesamte Anwendung sowieso neu schreiben
B) Änderungen sind nur auf die Datenzugriffsschicht beschränkt
C) Die Präsentationsschicht passt sich automatisch an
D) PostgreSQL ist in die Schichtenarchitektur eingebaut
Antwort anzeigen
Richtige Antwort: B
Richtige Schichtenarchitektur isoliert Technologieänderungen auf bestimmte Schichten. Beim Wechsel der Datenbank muss nur die Datenzugriffsschicht (Repositories, Verbindungscode) geändert werden. Die Business-Schicht ruft weiterhin dieselben Repository-Schnittstellen auf, und die Präsentationsschicht ist völlig unbeeinflusst. Diese Isolation ist ein wichtiger Vorteil des Musters.
Frage 8: Business-Schicht-Zuordnung
Wo sollte Domänenlogik wie “maximale Steigung aus Straßenmessungen berechnen” implementiert werden?
A) In der Präsentationsschicht (UI-Callbacks)
B) In der Business/Domänen-Schicht (Services oder Domänenmodelle)
C) In der Datenzugriffsschicht (Datenbankabfragen)
D) In den Konfigurationsdateien
Antwort anzeigen
Richtige Antwort: B
Domänenlogik gehört in die Business/Domänen-Schicht. Dies umfasst Berechnungen, Validierungen und Geschäftsregeln wie die Berechnung der maximalen Steigung aus Messungen. Solche Logik in der Präsentationsschicht (A) zu platzieren, koppelt sie an die UI und macht sie untestbar und nicht wiederverwendbar. Die Datenschicht (C) sollte nur Datenspeicherung und -abruf handhaben.
Frage 9: Client-Server-Rollen
In der Client-Server-Architektur, welche Komponente setzt typischerweise Geschäftsregeln durch?
A) Der Client (Browser oder Mobile App)
B) Der Server
C) Beide teilen die Verantwortung gleichermaßen
D) Keiner - eine separate Regel-Engine handhabt dies
Antwort anzeigen
Richtige Antwort: B
In der Client-Server-Architektur ist der Server die Autorität für Geschäftsregeln, Datenvalidierung und Sicherheitsdurchsetzung. Während Clients Validierung für bessere Benutzererfahrung durchführen können, muss der Server immer validieren, weil Clients umgangen oder manipuliert werden können. Sich nur auf clientseitige Validierung zu verlassen (A) schafft Sicherheitslücken.
Frage 10: Wann Microservices verwenden
Wann ist laut der Vorlesung eine Microservices-Architektur am geeignetsten?
A) Für kleine Teams, die ihre erste Anwendung bauen
B) Für Early-Stage-Produkte, die schnelle Iteration benötigen
C) Für große Teams, die unabhängige Koordination und unterschiedliche Skalierungsanforderungen haben
D) Für einfache Domänen mit unkomplizierten Anforderungen
Antwort anzeigen
Richtige Antwort: C
Microservices sind geeignet für große Teams, die unabhängig arbeiten müssen, wenn verschiedene Features unterschiedliche Skalierungsanforderungen haben, oder wenn Technologievielfalt benötigt wird. Die Vorlesung warnt ausdrücklich vor Microservices für kleine Teams (A), Early-Stage-Produkte (B) und einfache Domänen (D), weil der Koordinationsaufwand die Vorteile überwiegt.
Frage 11: Monolith vs. Microservices
Was ist ein wichtiger Vorteil monolithischer Architektur gegenüber Microservices?
A) Bessere unabhängige Skalierung von Komponenten
B) Einfacheres Deployment und geringerer Koordinationsaufwand
C) Einfacher verschiedene Technologien für verschiedene Features zu verwenden
D) Fehler sind besser isoliert
Antwort anzeigen
Richtige Antwort: B
Monolithische Architektur bietet einfacheres Deployment (einmal deployen, nicht mehrere Services koordinieren) und geringere operative Komplexität. Du deployst die gesamte Anwendung als eine Einheit, ohne dir Sorgen über Service Discovery, Netzwerklatenz zwischen Services oder verteiltes Debugging machen zu müssen. Unabhängige Skalierung (A), Technologievielfalt (C) und Fehlerisolation (D) sind Vorteile von Microservices, nicht von Monolithen.
Frage 12: Technical Spike Zweck
Was ist der Zweck eines Technical Spikes in der agilen Architektur?
A) Produktionscode so schnell wie möglich zu schreiben
B) Zeitlich begrenzte Recherche und Experimente vor architektonischen Entscheidungen durchzuführen
C) Den Planungsprozess zu überspringen und sofort mit dem Coden zu beginnen
D) Alle möglichen zukünftigen Anforderungen zu dokumentieren
Antwort anzeigen
Richtige Antwort: B
Ein Technical Spike ist zeitlich begrenzte Recherche (z.B. maximal 2 Tage), um architektonische Fragen vor einer Festlegung zu untersuchen. Zum Beispiel die Untersuchung von PostgreSQL vs. SQLite durch Erstellen eines Proof-of-Concept und Messen der Performance. Dies liefert fundierte Entscheidungen statt Vermutungen. Spikes dienen nicht dem Hetzen (A/C) oder umfangreicher Dokumentation (D) - sie sind fokussierte Experimente zur Reduzierung von Unsicherheit.
Frage 13: Emergente Architektur
Was bedeutet “emergente Architektur” im agilen Kontext?
A) Die Architektur wird komplett im Voraus entworfen, bevor mit dem Coden begonnen wird
B) Architekturentscheidungen werden inkrementell getroffen, während Muster aus funktionierender Software entstehen
C) Keine Architekturplanung ist nötig - einfach mit dem Coden beginnen
D) Die Architektur wird allein vom Projektmanager bestimmt
Antwort anzeigen
Richtige Antwort: B
Emergente Architektur bedeutet, genug Entscheidungen zu treffen, um zu starten (Sprache, Framework, Grundstruktur), funktionierende Software zu implementieren und zu refaktorieren, wenn Muster entstehen. Es ist nicht “keine Planung” (C) - du triffst trotzdem initiale Entscheidungen. Es ist nicht “alles im Voraus” (A) - du vermeidest Überdesign für hypothetische Zukunftsszenarien. Architektur entwickelt sich durch Retrospektiven und kontinuierliche Verbesserung.
Frage 14: Musterwert
Warum sind Architekturmuster laut der Vorlesung wertvoll?
A) Sie sind neue Erfindungen, die Projekterfolg garantieren
B) Sie sind bewährte Strukturen mit bekannten Trade-offs, die gemeinsames Vokabular und Community-Support bieten
C) Sie eliminieren die Notwendigkeit für jegliche individuellen Designentscheidungen
D) Sie machen alle Anwendungen identisch
Antwort anzeigen
Richtige Antwort: B
Architekturmuster sind wertvoll, weil sie Entdeckungen wiederkehrender Strukturen in erfolgreichen Systemen sind - keine Erfindungen (A). Sie bieten: bewährte Lösungen, gemeinsames Vokabular für Kommunikation, bekannte Trade-offs, die du analysieren kannst, und Community-Support. Sie eliminieren keine individuellen Entscheidungen (C) und machen Anwendungen nicht identisch (D) - du musst Muster trotzdem an deinen spezifischen Kontext anpassen.
Bewertungsübersicht
- 13-14 richtig: Ausgezeichnet! Du hast ein starkes Verständnis der Architekturmuster-Konzepte
- 10-12 richtig: Gutes Verständnis! Wiederhole die spezifischen Muster, die du verpasst hast
- 7-9 richtig: Ordentliches Verständnis. Gehe die MVC-, Schichtenarchitektur- und Microservices-Abschnitte nochmal durch
- Unter 7: Bitte wiederhole die Vorlesung sorgfältig, mit Fokus auf die drei Musterkategorien
Wichtige Erkenntnisse zum Merken
- MVC trennt Zuständigkeiten: Model (Daten/Logik), View (Präsentation), Controller (Koordination)
- Abhängigkeiten fließen abwärts: Präsentation → Business → Daten, niemals umgekehrt
- Keine Schichten überspringen: UI sollte niemals direkt auf die Datenbank zugreifen
- Technologie-Isolation: Richtige Schichten ermöglichen Datenbankwechsel ohne alles neu zu schreiben
- Domänenlogik in Business-Schicht: Nicht in UI-Callbacks oder Datenbankabfragen
- Server setzt Regeln durch: Vertraue niemals allein auf clientseitige Validierung
- Microservices sind nicht immer besser: Kleine Teams profitieren oft mehr von Monolithen
- Technical Spikes reduzieren Risiko: Zeitlich begrenzte Experimente informieren architektonische Entscheidungen
- Architektur entsteht: Starte mit genug Struktur, refaktoriere wenn Muster erscheinen
- Muster bieten Vokabular: Sie sind bewährte Lösungen, keine Erfindungen