Framework

Praxis-Nachtrag: Nutze Framework in einem Mini-Szenario. Eine kleine App soll einen Nutzer anmelden, eine Liste laden oder eine Bestellung speichern. Frage: An welcher Stelle taucht Framework auf, was würde ohne diesen Baustein fehlen, und welchen Fehler würdest du als Anfänger wahrscheinlich sehen? Diese Denkweise macht den Begriff sofort greifbarer als eine reine Definition.

Beispiele:

• Web: Django (Python), Ruby on Rails, Angular (JS).
• Game: Unity, Unreal Engine.

Du schreibst keinen Start-Code (main()). Du füllst Lücken: "Hier ist mein Controller-Code." Das Framework startet, lädt deinen Code und ruft ihn im richtigen Moment auf.

1. Opinionated vs. Unopinionated

• Opinionated (Django/Angular): "Es gibt genau einen Weg, das zu tun." Best Practices sind erzwungen. Gut für Teams (Code sieht immer gleich aus).
• Unopinionated (Flask/React): "Mach was du willst. Hier ist ein Router, den Rest such dir selbst." Flexibler, aber man muss mehr entscheiden (und kann mehr falsch machen). React ist eigentlich eine Library, wird aber oft wie ein Framework genutzt.

2. Lock-In Effekt

Wenn du deine App in Angular baust, bist du mit Angular verheiratet. Ein Wechsel zu React bedeutet: Alles wegwerfen und neu schreiben. Bei Libraries ist der Wechsel einfacher (nur eine Funktion tauschen). Wähle dein Framework weise! Es ist eine Entscheidung für Jahre.

3. Lifecycle Hooks

Da das Framework den Ablauf kontrolliert, gibt es dir "Haken" (Hooks), wo du eingreifen darfst. ngOnInit (Angular), componentDidMount (React), on_request_start (Flask). Du musst den Lebenszyklus des Frameworks verstehen, sonst läuft dein Code zur falschen Zeit (z. B. bevor die Datenbank da ist).

1. Inversion of Control (Das Hollywood-Prinzip)

Der technische Unterschied zwischen Library und Framework ist radikal: IOC (Inversion of Control) oder das "Don't call us, we call you" Prinzip. Mit einer Library (z.B. Lodash) schreibst du den Main-Loop. Dein Code hat die Kontrolle. Du holst dir via import nur Werkzeuge aus der Kiste. Beim Framework (z.B. Spring Boot) liegt der Main-Loop tief im Spring-Code verborgen. Das Framework bootet, scannt per Reflection all deine Java-Klassen nach @Controller Annotationen, baut intern eine massive Dependency-Graphen Tabelle auf, öffnet den Webserver und weckt deinen kleinen Codeblock erst genau aus dem Schlaf auf, wenn der HTTP Request von Client X hereinfliegt. Das Framework ist der Boss.

2. Event-Loop Blockierung in Single-Thread Frameworks

Moderne JavaScript-Frameworks (Node.js/Express) laufen Single-Thread (ein einziger CPU Core für 10.000 User). Ihre Macht ist asynchrone I/O ("Warten auf DB frisst keine CPU"). Die Gefahr liegt im Framework-Szenario, wenn der Dev CPU-schwere Logik in den Framework-Controller zwängt (z.B. Bild-Kompression 4K). Der V8-Event Loop wird dabei blockiert (Hogging). Während dein Controller für User A das Bild 6 Sekunden rechnet, wartet User B auf den Login. Frameworks reagieren extrem fragil auf synchrone CPU-Blocker (Das Framework kann andere HTTP-Requests nicht mehr reinlassen). Lösung hier: Worker Threads via Message Queue abspalten (das Framework bleibt exklusiv für Ingress-Triage).

3. Dependency Injection Containern

Was ist das "Herz" fast aller Backend-Frameworks (Spring/Angular/NestJS)? Ein Container. Statt new DatabaseService() hart in deiner Klasse aufzurufen, schreibst du nur in den Konstruktor: constructor(private db: DatabaseService). Das Framework bootet ("Wiring Phase"), liest den Architekturbaum (IoC Container), instanziiert den Service als Singleton exakt ein einziges Mal und spritzt (inject) diesen in alle 50 Controller, die ihn anfragen. Tauscht du später MySQL gegen MongoDB aus, änderst du nur EINE Zeile in der Framework-Config. Der Container-Bootloader injiziert Magie-artig den neuen Driver umsonst in alle Klassen.