MVC (Model View Controller)

Klassisch (Ruby on Rails, Laravel, Django): URL /users/1 ruft UserController auf. Controller fragt UserModel nach User 1. Controller nimmt Daten und rendert user_view.html. Browser zeigt HTML.

1. Fat Model, Skinny Controller

Eine goldene Regel. Packe die Logik ("Darf User das kaufen?") ins Model. Der Controller soll nur delegieren ("Wenn Klick, dann Model.save()"). Wenn der Controller 1000 Zeilen hat, machst du was falsch.

2. MVC im Frontend?

Früher (Backbone.js) versuchte man MVC im Browser. Hat nicht gut funktioniert. Heute (React/Vue) nutzt man eher Komponenten-basierte Architektur oder MVVM. Dort sind View und Logik oft enger verknüpft (in einer File), weil Interaktivität sofortiges Feedback braucht.

3. MVP (Model View Presenter)

Eine Variante. Bei MVC darf die View manchmal das Model lesen. Bei MVP ist die Trennung strikter: View und Model kennen sich gar nicht. Der Presenter schiebt alles hin und her. Wichtig für Testbarkeit (Unit Tests für Presenter sind einfach, weil keine UI dran hängt).

Active Record vs. Data Mapper (Der Model-Konflikt)

Wie genau interagiert das "Model" mit der Datenbank? Hier existieren zwei philosophische Lager in MVC-Frameworks.

• Active Record (z.B. Ruby on Rails, Eloquent in Laravel): Das Model ist die Datenbankzeile. user = User.new; user.save(). Das Model erbt direkt von der ORM-Basisklasse und koppelt Geschäftslogik massiv an die Datenbankstruktur. Super für schnelle CRUD-Apps, bricht aber oft das Single Responsibility Principle (SRP).
• Data Mapper (z.B. Doctrine, Hibernate): Das Model ist ein reines, dummes "Plain Old Java/PHP Object" (Entity). Es weiß nichts davon, wie man sich speichert. Der "Entity Manager" (der Data Mapper) übernimmt die Übersetzung zwischen dem Objekt und dem SQL-Insert. Dies entkoppelt die DB radikal von der Logik (besser für komplexe Enterprise-Systeme).

Domain-Driven Design (DDD) & Service Layers

Sobald eine MVC-Applikation skaliert, wird der "Fat Model"-Ansatz toxisch. Zehntausend Zeilen Code im UserModel. Die Lösung ist das Einführen neuer Layer, die im klassischen MVC nicht definiert sind (oft inspiriert durch Domain-Driven Design). Man führt Service Layer ein. Der Controller empfängt den Request und ruft nicht das Model auf, sondern CheckoutService.processOrder(user, cart). Der Service orchestriert Stripe, das Email-System und das Database-Model. Das Model selbst degeneriert zur reinen Datenstruktur. Diese Architektur entlastet Controller und Model gleichermaßen und macht Fachlogik isoliert testbar.

Inversion of Control (IoC) im Controller

In modernen Spring-Boot- oder .NET-MVC-Anwendungen instanziiert der Controller niemals seine Abhängigkeiten mit new Database(). Man nutzt Konstruktor-Injektion (Dependency Injection / IoC). Das Framework injiziert das Model Interface in den Controller. Der gigantische Vorteil beim Testing: Du kannst dem Controller im Unit-Test problemlos einen Mock-Datenbank-Service unterschieben, weil der Controller nur das Interface, nicht aber die konkrete SQL-Klasse kennt.